Comments (17)
I'd prefer to define them properly, to be dependent on a host-language-defined editability boolean; I highly doubt that much content is purposely relying on :read-write matching type=text but not type=color. And if possible, define :read-only to also depend on that boolean, so elements that don't have an editability concept at all don't match either.
from csswg-drafts.
Well, these pseudo-classes were originally created for XForms 1.1:
Selects any core form control bound to a node with the model item property readonly evaluating to true or false (respectively).
So the whole point wasn't that the element was interactive, but that it was bound to a node in the data model that had the property of being read-only. Read-only is a property of the underlying data model, not the control.
In HTML, the control elements have an implicit data model, but nothing has changed. The "readonly" attribute applies only to Web Forms elements. The other elements don't have an implicit data model. Thus, it's my feeling that :read-only should only apply to controls that are specifically set with the"readonly" attribute, and :read-write should match all controls that aren't "readonly". If we need a pseudo-class for editable elements, use something like :editable or :mutable instead of :read-write. We should never have a situation where :read-write is just :not(:read-only) or vice versa.
from csswg-drafts.
I feel exactly as @fantasai does:
If it's Web-compatible and no-one else feels strongly about keeping it,
I don't mind. But I don't have that data.
from csswg-drafts.
Any opinion on the semantics in the event that removing it isn't web-compatible?
from csswg-drafts.
So, any vendor(s) want to add telemetry to see whether these can be removed?
Complete shot in the dark: @foolip ?
from csswg-drafts.
SELECT * FROM (
SELECT page, url, REGEXP_EXTRACT(LOWER(body), r'((?:.){50}:read-(?:only|write)\s*\{(?:.){50})') AS match
FROM [httparchive:har.2016_05_15_chrome_requests_bodies]
) WHERE match != "null"
326 resources match (out of 496,446 pages).
results-20160610-100007.csv.zip
from csswg-drafts.
Some observations from skimming the CSV:
:read-write
only occurs 1 time. Perhaps someone could run another query, limited to just:read-write
, to see how (un)popular it is specifically?- 58 are http://carrotquest.io and 30 are http://www.drift.com , both of which are Olark-ish live text chat widgets
- 20 are http://tagboard.com widgets, where the selector suggests it's being used as part of an account settings screen (
.dashboard .content .account-tab#account-settings input:read-only
) - 17 are websites using the https://www.muicss.com CSS framework
from csswg-drafts.
FYI.
Google Chrome 52 has counters for :read-only and :read-write.
- :read-only is used in 0.006% of page views: https://www.chromestatus.com/metrics/feature/timeline/popularity/1377
- :read-write is used in 0.004% of page views: https://www.chromestatus.com/metrics/feature/timeline/popularity/1378
Usually Chromium project assumes features with such values are removable.
from csswg-drafts.
from csswg-drafts.
So, any vendor(s) want to add telemetry to see whether these can be removed?
Complete shot in the dark: @foolip ?
Sorry, I just fixed my email filters to make direct mentions like this stand out from all other GitHub mail. Glad to see my services weren't needed after all :)
from csswg-drafts.
From my (admittedly HTML-centric) perspective as a web developer using CSS, there's a definite use case for these pseudo-classes, but changing their meaning slightly would make them far more useful.
I see them as useful to allow a selector to match all text entry elements in HTML, which is otherwise not possible. The linked article can only suggest variations on this fundamentally flawed approach:
input:not([type]), /* all non-declared types */
input[size], /* text, search, tel, url email, or password */
input[type^=date], /* date, datetime, datetime-local */
input[type=color],
input[type=week],
input[type=month],
input[type=time],
input[type=number],
input[type=range] {
/* styles */
}
This approach is problematic in many ways:
- It's unnecessarily clumsy and verbose.
- It presumes that the
size
attribute will be specified on all text inputs, which may not be the case. - It is fundamentally tied to a specific user-agent - in fact, to a specific version of a specific user-agent - because user agents are rightly given free rein regarding the UI they present for the different
<input>
types, and do in fact make different choices from vendor to vendor and version to version. - It cannot account for new
<input>
types that may be added to the HTML specification in the future
As currently specified, the :read-write
pseudo gets partway to meeting this need, but does not offer a way to match readonly (other than a [readonly]
attribute selector) or disabled text inputs because :read-only
is defined too broadly.
I would suggest changing the specification of :read-only
to match only elements that could support :read-write
but are currently readonly or disabled.
from csswg-drafts.
from csswg-drafts.
They don't do that, tho. As the SO answers state, :read-write doesn't match disabled form controls (tho it does in Chrome, at least), while it does match <textarea>, which isn't what you want.
Actually I would want it to match <textarea>
, and anything that's contenteditable
as well.
Regardless of how we decide this, it won't support your use-case properly.
Perhaps I'm misunderstanding the discussion here, and if so I apologise. I thought that the issue was that the currently specified behaviour of :read-only
and :read-write
is problematic, vague, and doesn't have clear use cases; and that (probably because of these issues) they aren't widely used and maybe aren't worth continuing to support at all.
My suggestion was to change the specified behavior of those selectors to give them a clearer reason for existence, rather than removing them entirely or continuing to support something that's not especially useful or used.
Specifically, my suggestion is to keep the behaviour of :read-write
essentially unchanged, and define it explicitly as referring to any kind of editable text entry (that is, <textarea>
and all <input>
types that render as textboxes, as long as they aren't readonly
or disabled
, along with anything contenteditable
), and change the definition of :read-only
to mean "editable text entry controls where editing is disabled", so it'd match <textarea>
s and textbox <input>
s that are readonly
or disabled
.
Is there some reason why such a change can't be considered?
from csswg-drafts.
The Working Group just discussed [selectors] :read-only and :read-write
, and agreed to the following resolutions:
RESOLVED: keep the selectors in the spec and work on defining and test cases as appropriate.
The full IRC log of that discussion
<dael> Topic: [selectors] :read-only and :read-write<dael> github: https://github.com//issues/127
<dael> fantasai: Issue was filed to say they don't have a sensible def. or interop. FF doesn't support them. Proposal was to remove them. Alt was come up with a useful def. that's specced.
<dael> fantasai: Easiest is remove, but ti's a Q for the WG.
<dael> Rossen_: Based on Chrome 52 data seems like it's below threshold of what google would consider not removing. Q to the chrome folks, are you willing to remove this?
<dael> ericwilligers: If it's low I think if that's what the group pref. We haven't discussed.
<dael> Rossen_: I don't want to resolve now and then someone say nope we won't remove. Good we took exersize to review but no action will follow. It's good to have more commitment before we resolve. If you guys aren't okay to remove from the get go no reason to talk.
<fantasai> Testcase - http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%3Aread-write%2C%20body%20%7B%20background%3A%20green%3B%20%7D%0A%3Aread-only%2C%20body%20%7B%20background%3A%20green%3B%20%7D%0A%3C%2Fstyle%3E
<fantasai> It is not supported in Firefox afaict.
<fantasai> and parses as invalid
<dael> florian: Seems to be that the dsicussion isn't that it's useless but that it's not specced right. Maybe something sayinng this might be useful but we didn't get it right, feedback please in the spec.
<dael> ericwilligers: Has anyone come up with a different spec for that?
<dbaron> I think Firefox supports :-moz-read-only and :-moz-read-write
<dael> tantek: I think it came from a really old draft of css ui and then was assimilated into selectors. I recall there was some type of x-forms back in the day but I don't know if that's used anymore. Prob fine to drop from a modern we don't have use cases. Esp. if the threashold is low enough.
<dael> Rossen_: Is FF only one not supporting?
<dael> dbaron: We have support with moz prefix, but not unprefixed.
<dael> tantek: Regarding fixing b/c it's web exposed now there's a race condition where if it's low enough to remove we should do so to avoid having an emerging compat issue while we figure out how it should work. Then it can procceed without pressure.
<florian> tantek, fair enough
<dael> ericwilligers: I think usage has gone up. It seems to be 1.4% on the counter. So the thing you worried about has happened.
<dael> Rossen_: We're shipping unprefix. Chrome too. Not sure webkit. myles are you shipping it?
<dael> ??: Give me a second.
<ericwilligers> s/1.4%/.4%/ https://www.chromestatus.com/metrics/feature/timeline/popularity/1377
<Rossen_> s/??/mylies/
<Rossen_> s/mylies/myles/
<ericwilligers> 0.2% for read-write https://www.chromestatus.com/metrics/feature/timeline/popularity/1378
<dael> Rossen_: While we wait. ericwilligers you're sugegsting cunnet stats say we can't remove?
<dael> ericwilligers: Correct.
<dael> Rossen_: So I guess this is a moot point. That's why we wanted to have the illing to deprecate discussion. So the uptick in usage is too large to remove. So as brought by florian we can't remove so how do we fix them?
<dael> Rossen_: If we're not ready to discuss we can resolve this issue as not removing from spec and then we can work on further definition sep.
<dael> Rossen_: Not sure about fantasai if she's still tring to connect.
<fantasai> sgtm
<dael> Rossen_: Obj to resolve on keeping the properites as-is based on usage data and work on further defining their behavior?
<dael> myles: Our rendering is same as chrome, different then FF.
<dael> Rossen_: FF passes if you add the prefix.
<dael> Rossen_: Proposal is keep the selectors in the spec and work on defining and test cases as appropriate.
<dael> Rossen_: Obj?
<dael> RESOLVED: keep the selectors in the spec and work on defining and test cases as appropriate.
from csswg-drafts.
Since OP is about the HTML Standard, why isn't the issue raised against the HTML Standard?
from csswg-drafts.
Let's dupe this against whatwg/html#3501.
from csswg-drafts.
I agree with @MatthewRaymond
I think it is very unintuitive, that such css
/* both matches <select> */
select:read-only {}
select:not([readonly]) {}
/* both matches <div> */
div:read-only {}
div:not([readonly]) {}
will be applied to such html
<div></div>
<select></select>
from csswg-drafts.
Related Issues (20)
- [css-color-hdr] Add interpolation between multiple values of dynamic-range-limit HOT 3
- [css-grid-3][masonry] Shift `masonry` keyword to `grid-auto-rows/columns`? HOT 1
- [css-align-3] Incorrect syntax for <baseline-position> HOT 2
- [css-grid-3][masonry] Make auto-fit do things
- [css-grid-3] Make align-self/justify-self align including adjacent extra space HOT 8
- [web-animations-2] Why are Range Configs Applied to the Animation and not the Timeline?
- [meta] drafts.csswg.org is not listing drafts
- [cssom-1] Setting a custom property value to empty string HOT 1
- [css-color-5] RCS channel keywords interaction with calc() is underspecified HOT 2
- [css-next] Call for feedback: RFC open for CSS Levels categorization
- [css-sizing] Proposal: `default-width` CSS property HOT 1
- Editorial suggestions from HR HOT 3
- [css-variables-2][css-properties-values] Constants in CSS HOT 2
- [css-nesting][selectors] Behavior of & at the root of a stylesheet HOT 8
- [CSS-UI] caret-shape: block/underscore and overflow
- T
- [css-fonts-5] Computed value for font-size-adjust HOT 1
- [css-ui] `outline-style` should work for both UA and author values around anonymous block boxes
- [css-values-5] Interpolating calc-size() more generally HOT 22
- [selectors] Adding a `:heading()` selector for headingoffset? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csswg-drafts.