Re: [whatwg] False orthogonal nature :read-only and :disabled in WF2
On Tue, 15 Aug 2006, Matthew Raymond wrote:
Ian Hickson wrote:
I understand (and agree) that WF2 disagrees with CSS3UI and Selectors
here. I believe the error is in CSS3UI and in Selectors.
I would agree with that, although I think we disagree as to what the
error is.
Having them be orthogonal is far more useful to authors. For example,
imagine the following stylesheet:
:read-only::after { content: ' (Read-only)'; }
:disabled { color: gray; }
You wouldn't want all the :disabled fields to suddenly say read-only
just because they weren't relevant. You wouldn't want to have to say:
:not(:disabled):read-only { ... }
...every time you wanted to style the fields which, when enabled, still
can't be edited.
I'll see if I can get Selectors updated.
Please go back and address the concerns that I posted on www-style in
detail when you update Selectors.
It turns out this is (now?) only in CSS3 UI, which doesn't have a
maintainer right now.
There is a clear double standard here. I had a problem with the way
:read-only was defined, that it applied to elements that did not have a
|readonly| attribute, but you made it clear that I would have to go
through www-style to get it changes in the CSS3-UI specification before
getting a related change made in the WF2 spec.
Well, :read-only has always been intended to apply to everything. There's
a difference between the basic concept of the pseudo-class and the exact
definiton of the pseudo-class.
That's the point. The :read-only pseudo-class should never have been
defined as applying to everything. It should apply to markup that has a
defined read-only state. The text-based input of a control is not
comparable to a |contenteditable| region of HTML. For instance, if you
can't edit the markup of an input element, but you can edit the text
in the control, then at the markup level, the control is read-only, but
the actual control contents are read-write. Conversely, what if you have
an input readonly control as the child of an element with
|contenteditable| enabled? In this case, the markup actual says
readonly, but it might still be considered read-write because the
markup can be changed.
I agree that I was applying a double standard here (I am following CSS3
UI when it comes to it saying that :read-only applies to everything, and
not following it when it comes to saying that :read-write doesn't apply
to disabled controls).
I've made HTML5 say that :read-write doesn't apply to disabled controls.
Yet when you have a problem with the definition of the
_EXACT_SAME_PSEUDO-CLASS_, you just change the WF2 spec to produce
orthogonally where none existed in the collective W3C specs.
Perhaps you can explain to me how you justify this.
I'm trying to make the specs be useful to authors.
Having to style control elements using selectors like
html|input[readonly] as opposed to :readonly doesn't strike me as
more useful for authors. Also, note that for stuff like XForms, you can
end up in a situation where there's no clear way of styling a
read-only control, since the read-only property may not exist
directly on the element. Of course, if we start talking about other XML
languages here, we're getting off topic...
Yeah. I'm not really sure what to do about this.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling of area elements (as displayed within referencing image)
On Thu, 10 May 2007, L. David Baron wrote: The interaction of area elements with CSS styling is not defined in HTML 5. Since area elements are particularly unusual (in that they appear an arbitrary number of times, whenever their containing map is linked to by an img), I think it should be. Fixed. Please let me know if the new text is ok: http://www.whatwg.org/specs/web-apps/current-work/#image-maps-0 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [wf2] :read-write pseudoclass description issue
On Mon, 24 Sep 2007, Rikkert Koppes wrote: http://www.whatwg.org/specs/web-forms/current-work/#relation :read-only Matches form control elements that have the |readonly http://www.whatwg.org/specs/web-forms/current-work/#readonly| attribute set, and to which the |readonly http://www.whatwg.org/specs/web-forms/current-work/#readonly| attribute applies (thus radio buttons will never match this, regardless of the value of the attribute), as well as elements defined by this specification that are not form controls (namely |form|, |label|, |datalist http://www.whatwg.org/specs/web-forms/current-work/#datalist|, |option|, |optgroup|, and |fieldset| elements). :read-write Matches form control elements that do not have the |readonly http://www.whatwg.org/specs/web-forms/current-work/#readonly| attribute set (including |password http://www.whatwg.org/specs/web-forms/current-work/#password| controls, although technically they should be called writeonly), or to which the attribute doesn't apply (such as radio buttons). A disabled control can still match this pseudo-class; the states are orthogonal. I believe the term orthogonal is incorrect here. Following (the rest of) the text, it occurs to me these pseusoclasses are opposite (mutually exclusive), while orthogonal means, they can both apply, independent of eachother. The new text doesn't mention this. Let me know if it's ok: http://www.whatwg.org/specs/web-apps/current-work/#matching-html-elements-using-selectors Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [wf2] :read-write pseudoclass description issue
On Wed, 11 Feb 2009, Rikkert Koppes wrote: However, reading the previous text (in the quoted mail below) again, it occurs to me that was actually intended was A disabled control can still match this pseudo-class; the [disabled and read-write] states are orthogonal. In that sense, the current text is quite a shift. Yeah, this was done to line up more closely with CSS3 UI's definitions. I don't really think they make sense, but it's not HTML5's place to go against what the CSSWG decided. furthermore, some text remarks at [1] - on the read-write definition, first bullet, immutable already includes disabled controls [2] Fixed. text remarks at [2] - on the note (The readonly attribute can also in some cases make an input element immutable.): in which cases not? [3] seems to imply all cases, this should be made clear at the note. It doesn't, e.g., make a radio button immutable. I'm not sure how to make it clearer without repeating spec text over and over though. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [wf2] :read-write pseudoclass description issue
On Wed, 11 Feb 2009, Rikkert Koppes wrote: At [1] I'd suggest changing the second sentence to When specified and applicable, the element is immutable. [1]: http://www.whatwg.org/specs/web-apps/current-work/#attr-input-readonly Yeah, I keep thinking of doing something like that. The reason I haven't yet is that I don't want to go down the route of people seeing that and thinking that that means that other things in that section might apply even when they don't (the intro to that section explicitly says that nothing there applies if the attributes aren't applicable). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [wf2] :read-write pseudoclass description issue
I see your point, to go for another route, maybe you'd just edit the source of the problem (the note), remove it and include a text similar to the remark about the disabled attribute. I.e: --- When an input element is disabled, it is immutable. When an input element is readonly, it is immutable. --- However, there is no readonly concept defined (maybe this will clarify more, but actually I think it's likely to complicate things even more). Hence, another suggestion could be: --- An input element to which the readonly attribute applies and has that attribute specified, is immutable. --- Cheers, Rikkert Koppes Ian Hickson wrote: On Wed, 11 Feb 2009, Rikkert Koppes wrote: At [1] I'd suggest changing the second sentence to When specified and applicable, the element is immutable. [1]: http://www.whatwg.org/specs/web-apps/current-work/#attr-input-readonly Yeah, I keep thinking of doing something like that. The reason I haven't yet is that I don't want to go down the route of people seeing that and thinking that that means that other things in that section might apply even when they don't (the intro to that section explicitly says that nothing there applies if the attributes aren't applicable).
Re: [whatwg] [wf2] :read-write pseudoclass description issue
On Wed, 11 Feb 2009, Rikkert Koppes wrote: I see your point, to go for another route, maybe you'd just edit the source of the problem (the note), remove it and include a text similar to the remark about the disabled attribute. I.e: --- When an input element is disabled, it is immutable. When an input element is readonly, it is immutable. --- However, there is no readonly concept defined (maybe this will clarify more, but actually I think it's likely to complicate things even more). Hence, another suggestion could be: --- An input element to which the readonly attribute applies and has that attribute specified, is immutable. The problem with those is that the requirement in question is already in the readonly section, along with some more requirements, and I don't want to split the requirements up to be all over the place... Instead I've annotated the note a little to make it slightly clearer why it's only sometimes. Does that help? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] code in in body insertion mode (8.2.5)
On Mon, 12 Jan 2009, Kartikaya Gupta wrote: code is listed in the formatting category of elements, but isn't dealt with in the same way as other formatting elements when in the in body insertion mode. Currently it will fall through to the any other start tag case, so the note in that case that says This element will be a phrasing element is incorrect. I'm assuming that the code element should be listed along with the other formatting elements (b, big, em, etc.) for the in body insertion mode. Is that correct? On Fri, 16 Jan 2009, Kartikaya Gupta wrote: Oh, it's also missing from the end tags section (i.e. /code when in body insertion mode). Fixed. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] Rendering of interactive content
On Tue, Feb 10, 2009 at 10:30 PM, Ian Hickson i...@hixie.ch wrote:
If the UA suddenly displays hyperlinks in green and I decided that my
background is green, the user will complain with me, not with the UA (and
will probably switch to a different website)
Authors should never the background colour without setting the foreground
colour. So that would be the author's fault.
I don't think that's relevant. If I, as an author, use the rule
body { color: white; background: green; }
and the UA uses the rule
:link { color: green; }
then links would be invisible despite my background color. Although
authors are encouraged to always set colors and backgrounds together,
UAs conventionally do *not* do this for links, for fairly good reason.
You could say that not only should authors never set the background
color without setting the foreground color, they should also never set
the background color without setting the *link* color. But this still
doesn't help if the UA (or a user stylesheet) uses
span { color: green; }
for some strange reason (not much stranger than green links by
default!), in which case everything is still messed up.
I don't think there's any way around this. If a UA sets unexpected
style rules, it *will* break some sites. I imagine that the response
to this is that while this may be so, it's possible that in some cases
it will be a tradeoff against platform integration or something, and
so it should still be up to the implementers to decide whether it's a
good tradeoff in their case. The expectation would be that for
conventional browsers, it won't be. This is pretty much just the
definition of should in RFC2119.
Re: [whatwg] [html5] Rendering of interactive content
Aryeh Gregor writes:
On Tue, Feb 10, 2009 at 10:30 PM, Ian Hickson i...@hixie.ch wrote:
If the UA suddenly displays hyperlinks in green and I decided that
my background is green, the user will complain with me, not with
the UA (and will probably switch to a different website)
Authors should never the background colour without setting the
foreground colour. So that would be the author's fault.
I don't think that's relevant.
It is relevant, because as you then say:
If I, as an author, use the rule
body { color: white; background: green; }
and the UA uses the rule
:link { color: green; }
then links would be invisible despite my background color.
That is precisely an instance of an author setting a background colour
without a foreground colour -- specifically the author set the
background colour used on links without setting the foreground colour
for links.
If an author sets a background colour then she needs to set the
foreground colour for all text that appears on it, anywhere.
Although authors are encouraged to always set colors and backgrounds
together, UAs conventionally do *not* do this for links, for fairly
good reason.
Browsers do of course (typically) set both together -- in that they
provide a default background colour, plus foreground colours for visited
links, unvisitied links, and non-link text. If an author overrides one
of those four then he generally needs to override all of them (except in
circumstances where he knows the area in question won't have any links,
or any-non links, or any text).
You could say that not only should authors never set the background
color without setting the foreground color, they should also never set
the background color without setting the *link* color.
Yup.
But this still doesn't help if the UA (or a user stylesheet) uses
span { color: green; }
for some strange reason
Indeed. That would be strange. So strange that I really don't see why
HTML 5 should be concerned with it, and I certainly don't think there's
anything it can do about it:
* A user-agent that does something as arbitrary as the above is unlikely
to achieve much market share.
* A user style-sheet that does the above has been presumably set by a
user who wants it. Let her.
(not much stranger than green links by default!),
It's significantly stranger, for a couple of reasons:
* Links are a distinct type of element with a specific purpose.
span-s convey no semantics of their own, and are used for multiple
purposes.
* Links are conventionally a different colour from other text; span-s
aren't. Prefering links to be green rather than blue is a minor
change, possibly one of aesthetics or to assist somebody who has
trouble distinguishing certain colours. Whereas prefering span-s to
be green rather than indistinguishable from the surrounding text is
adding in a distinction not normally seen.
in which case everything is still messed up.
Yes. Users can choose to implement custom styles which mess things up.
Users are free to do that if they want.
They may even have good reasons for doing so; for example, when
attempting to debug a website it can be useful to make various elements
different colours to show which is rendered where. It's possible that
at some point I want to debug your website, or examine how you achieved
a particular effect, and that making your span-s green will assist me
in doing that.
I don't think there's any way around this.
We don't want a way round it. It's a feature that users are in
ultimate control.
Smylers
Re: [whatwg] [html5] Rendering of interactive content
On Wed, Feb 11, 2009 at 8:36 AM, Smylers smyl...@stripey.com wrote:
That is precisely an instance of an author setting a background colour
without a foreground colour -- specifically the author set the
background colour used on links without setting the foreground colour
for links.
. . .
Browsers do of course (typically) set both together -- in that they
provide a default background colour, plus foreground colours for visited
links, unvisitied links, and non-link text.
I interpret authors should always set background and foreground
colors together as no single CSS rule should set 'background'
without setting 'color' or vice versa. I can't figure out exactly
how you're interpreting it.
The point is that to ensure that the foreground and background don't
conflict, you must always set foreground and background colors *in the
same CSS rule*. As long as all stylesheets observe this principle,
there will never be a mismatch. Either the color and background are
overridden both at once, or not at all, since the cascade works on a
rule-by-rule basis, not property-by-property.
The browser is the one that's failing to observe the principle in this
case, and the author is observing it. The author is *not* setting the
background color for :link, nor the foreground color. The author is
only setting the colors for body. On the other hand, the UA is
setting the foreground color for :link, but is *not* setting a
background color for :link -- only for body. If you put the rule
:link { color: blue; } into the W3C CSS validator, it will warn you
that you're setting color without setting background, regardless of
whether there's any inherited color you've set.
If an author overrides one
of those four then he generally needs to override all of them (except in
circumstances where he knows the area in question won't have any links,
or any-non links, or any text).
So you're saying links are a special case for this principle? Why?
UAs might just as reasonably change the colors of other elements as
well. It's only convention that says they only change the color of
links. But that exact same convention says that the color of links is
blue.
It's significantly stranger, for a couple of reasons:
* Links are a distinct type of element with a specific purpose.
span-s convey no semantics of their own, and are used for multiple
purposes.
So instead, suppose it were something like:
strong { color: red; }
In fact, though, green spans would not be significantly less common in
UA default stylesheets than green links -- as far as I know, neither
has ever occurred, certainly not in a notable browser. That's what I
meant by saying it would be not much stranger. Conceptually it's
stranger, but practically it's not.
* Links are conventionally a different colour from other text; span-s
aren't. Prefering links to be green rather than blue is a minor
change, possibly one of aesthetics or to assist somebody who has
trouble distinguishing certain colours. Whereas prefering span-s to
be green rather than indistinguishable from the surrounding text is
adding in a distinction not normally seen.
Yes, links are conventionally a different color from other text. More
particularly, they're conventionally *blue*. Every color browser I
have ever heard of back to the dawn of the Web uses blue for links.
NCSA Mosaic 0.6 beta already used blue for links:
http://gladiator.ncsa.uiuc.edu/Images/press-images/mosaic.6beta.tif
I have never heard of any exception. If you're saying that authors
should expect browsers to behave conventionally in not changing the
colors of non-links, I can't see how you would say that authors
shouldn't expect them to behave conventionally in making links blue.
Either the UAs are adopting the universal standards that everyone
everywhere has always used, or they're doing heaven knows what.
Yes. Users can choose to implement custom styles which mess things up.
Users are free to do that if they want.
We aren't talking about user stylesheets here, we're talking about
browser default stylesheets. HTML5 does not mention user stylesheets,
as far as I'm aware.
We don't want a way round it.
We always want a way around the possibility of sites breaking due to
different assumptions between UA and author. That's what standards
are *for*. In this case, however, it's not feasible to mandate a
single default rendering for all UAs. Clearly text-based browsers,
monochrome browsers, screen readers, etc. need to use different rules.
Therefore sites will sometimes break in browsers they weren't
designed for, and this is unfortunate, but it's not something HTML5
can prevent.
Re: [whatwg] [html5] Rendering of interactive content
Smylers wrote: That is precisely an instance of an author setting a background colour without a foreground colour -- specifically the author set the background colour used on links without setting the foreground colour for links. If an author sets a background colour then she needs to set the foreground colour for all text that appears on it, anywhere. Sorry, but that's just not reasonable. Especially because some of the text is not even stylable directly by the author (but might be by the UA stylesheet). -Boris
Re: [whatwg] [html5] Rendering of interactive content
Aryeh Gregor writes: On Wed, Feb 11, 2009 at 8:36 AM, Smylers smyl...@stripey.com wrote: That is precisely an instance of an author setting a background colour without a foreground colour -- specifically the author set the background colour used on links without setting the foreground colour for links. . . . Browsers do of course (typically) set both together -- in that they provide a default background colour, plus foreground colours for visited links, unvisitied links, and non-link text. I interpret authors should always set background and foreground colors together as no single CSS rule should set 'background' without setting 'color' or vice versa. I can't figure out exactly how you're interpreting it. Ah, I see. Thanks for explaining that. I'm interpreting it as for each bit of text that you cause the background colour to be set for, also specify its foreground colour (and _vice versa_). So it's reasonable for a browser to set a background colour on body and know that other elements take their background from that. The point is that to ensure that the foreground and background don't conflict, you must always set foreground and background colors *in the same CSS rule*. As long as all stylesheets observe this principle, there will never be a mismatch. True, but that introduces other awkwardnesses. Given that many pages (or regions of pages) have a background colour shared across several elements, it's tedious to have to specify it for each one -- and also harder to change. If the default browser style-sheet explicitly specified the background colour for links (rather than letting the body background show through) then authors would have to override all of them, instead of just the body colour. I expect that would break many existing websites. Either the color and background are overridden both at once, or not at all, since the cascade works on a rule-by-rule basis, not property-by-property. On that basis transparent backgrounds are useless, since you can never be sure that somebody else won't change the background colour of the parent element without ensuring none of its content's text colours clash. HTML elements nest. People expect that setting a background on an elment makes it appear behind all nested elments it contains. Let's work with that, not against it. The browser is the one that's failing to observe the principle in this case, and the author is observing it. The author is *not* setting the background color for :link, nor the foreground color. However she's including link elements inside a body for which she has set a background colour. Therefore, by my understanding, she's specified a background colour without a foreground colour. Your interpretation and my interpretation both 'work'. However, mine's less hassle to deal with (avoids proliferation of repetitive properties) and compatible with the extant web. If an author overrides one of those four then he generally needs to override all of them (except in circumstances where he knows the area in question won't have any links, or any-non links, or any text). So you're saying links are a special case for this principle? Why? Yes. Because links typically have a different colour -- as defined in the expected styling information given in HTML 5, and therefore authors should expect it. UAs might just as reasonably change the colors of other elements as well. It's only convention that says they only change the color of links. Yes. Conventions are good. But that exact same convention says that the color of links is blue. Fair point. But browsers have for a long time provided UI for users to specify other link colours in way that they haven't, for exmaple, the colour of headings or emphasized text. I'm sure some users take advantage of such UI (and wouldn't consider them to be user style-sheets; somebody clicking on such UI possibly isn't even aware of the concept of user style-sheets). There are plausible reasons why a user would want to set non-default colours, perhaps to make things easier to read. And if he sets a different text and background colour, he's likely to want to set different link colours too, so that they still stand out. Smylers
Re: [whatwg] [html5] Rendering of interactive content
On Wed, Feb 11, 2009 at 10:13 AM, Smylers smyl...@stripey.com wrote: Ah, I see. Thanks for explaining that. I'm interpreting it as for each bit of text that you cause the background colour to be set for, also specify its foreground colour (and _vice versa_). But that's not *possible* in CSS. Not within reason, anyway. You can't be expected to set color for all descendants. True, but that introduces other awkwardnesses. Given that many pages (or regions of pages) have a background colour shared across several elements, it's tedious to have to specify it for each one -- and also harder to change. It's the only way to be *sure* that things won't break (at least, you can be sure as long as everyone does it). On that basis transparent backgrounds are useless, since you can never be sure that somebody else won't change the background colour of the parent element without ensuring none of its content's text colours clash. Transparent backgrounds (i.e., no background) can still be set safely if you don't specify the text color. You only need to set the background when you set the text color. In practice, of course, this still isn't necessarily feasible. E.g., there may be a complicated background-image on body, which you can't respecify on descendants because it wouldn't line up properly. Then if you want to change the color of elements, you have to do it with a nonexistent (transparent) background. This means you'll have to accept the risk of things breaking if the user specifies a different style. Your interpretation and my interpretation both 'work'. However, mine's less hassle to deal with (avoids proliferation of repetitive properties) and compatible with the extant web. Well, what you call my interpretation is also the interpretation of whoever wrote the W3C CSS validator, AFAICT. It's *not* safe to set foreground color without background or vice versa, at least if you assume that your CSS might interact with arbitrary CSS from other sources. It may sometimes (even often) be worth the risk, however. I would say that what you're suggesting is an entirely different principle: stylesheet authors should manually set :link, :visited, and :hover foreground colors if they set any background color on any element that might contain a link, because they can't guarantee UA behavior otherwise. This is a much more specific point -- it doesn't cover interaction with author or user stylesheets and requires at most three rules per set of stylesheets. Fair point. But browsers have for a long time provided UI for users to specify other link colours in way that they haven't, for exmaple, the colour of headings or emphasized text. I'm sure some users take advantage of such UI (and wouldn't consider them to be user style-sheets; somebody clicking on such UI possibly isn't even aware of the concept of user style-sheets). Good point. I just checked and Firefox does in fact have such an option. So I'll agree that authors should always specify link colors to override the UA's stylesheet, if they specify backgrounds. My objection to what Ian said was incorrect.
Re: [whatwg] [html5] Rendering of interactive content
Aryeh Gregor writes: On Wed, Feb 11, 2009 at 10:13 AM, Smylers smyl...@stripey.com wrote: Ah, I see. Thanks for explaining that. I'm interpreting it as for each bit of text that you cause the background colour to be set for, also specify its foreground colour (and _vice versa_). But that's not *possible* in CSS. Not within reason, anyway. You can't be expected to set color for all descendants. You're right. It is possible if you presume foreground colours generally inherit (except for links) and backgrounds are generally transparent. Which apparently I was presuming, but omitted to state. Sorry for not thinking it through properly. True, but that introduces other awkwardnesses. Given that many pages (or regions of pages) have a background colour shared across several elements, it's tedious to have to specify it for each one -- and also harder to change. It's the only way to be *sure* that things won't break (at least, you can be sure as long as everyone does it). We can be sure that there are live websites out there currently not doing it! For a start, there are those which don't use CSS at all but on body set the bgcolor, text, link, and vlink attributes (another reason why links are special, since there aren't similar attributes for setting any other elements' colours). I would say that what you're suggesting is an entirely different principle: stylesheet authors should manually set :link, :visited, and :hover foreground colors if they set any background color on any element that might contain a link, because they can't guarantee UA behavior otherwise. This is a much more specific point -- it doesn't cover interaction with author or user stylesheets and requires at most three rules per set of stylesheets. Yes. And also the reverse (that if you set a link colour then set the background colour on either links or an ancestor element). I'll agree that authors should always specify link colors to override the UA's stylesheet, if they specify backgrounds. Hurrah -- in that case I think we're in agreement, and no changes to the spec are necessary. Smylers
Re: [whatwg] DOMTimeStamp binding
Kartikaya Gupta wrote: For Java, DOMTimeStamp is bound to the long type. For ECMAScript, DOMTimeStamp is bound to the Date type because the range of the integer type is too small. I get number in Opera and Firefox, and object in Webkit. Is there a reason Opera and Firefox bind the timestamps to numbers instead of the Date object? In the case of Gecko, simply because no one wrote the code to do it, I suspect. Are there any websites that depend on this behavior? Given the bugs Gecko has had with timeStamp (starting with inconsistent units for it), I doubt sites depend on anything much here. Also, I'm not sure if WebIDL should say something for this; right now the DOM IDL files do a typedef unsigned long long DOMTimeStamp, which corresponds to the Java binding but not the ECMAScript binding. Yep. That's exactly the IDL Gecko uses. -Boris
Re: [whatwg] DOMTimeStamp binding
On Feb 11, 2009, at 9:38 AM, Kartikaya Gupta wrote:
DOM 3 Core says this about DOMTimeStamp:
For Java, DOMTimeStamp is bound to the long type. For ECMAScript,
DOMTimeStamp
is bound to the Date type because the range of the integer type is
too small.
However, when I do this:
var e = document.createEvent('Events');
alert( typeof e.timeStamp );
I get number in Opera and Firefox, and object in Webkit.
I get number in WebKit.
-- Darin
Re: [whatwg] DOMTimeStamp binding
On Wed, 11 Feb 2009 10:06:14 -0800, Darin Adler da...@apple.com wrote:
However, when I do this:
var e = document.createEvent('Events');
alert( typeof e.timeStamp );
I get number in Opera and Firefox, and object in Webkit.
I get number in WebKit.
-- Darin
Interesting. What version did you try on? I used Chrome 1.0.154.48 and Safari
3.1 (525.13) on Windows.
Cheers,
kats
Re: [whatwg] DOMTimeStamp binding
On Feb 11, 2009, at 10:51 AM, Kartikaya Gupta wrote: Interesting. What version did you try on? I used Chrome 1.0.154.48 and Safari 3.1 (525.13) on Windows. The relevant version is the WebKit version rather than the Safari version. They have separate version numbers. I used WebKit/525.27.1 (the version that came with Safari 3.1.1) on Mac OS X and also WebKit tip of tree on Mac OS X. I also inspected the code and saw nothing that would create an object in the JavaScript binding for this. -- Darin
Re: [whatwg] Styling of area elements (as displayed within referencing image)
On Wednesday 2009-02-11 08:39 +, Ian Hickson wrote: On Thu, 10 May 2007, L. David Baron wrote: The interaction of area elements with CSS styling is not defined in HTML 5. Since area elements are particularly unusual (in that they appear an arbitrary number of times, whenever their containing map is linked to by an img), I think it should be. Fixed. Please let me know if the new text is ok: http://www.whatwg.org/specs/web-apps/current-work/#image-maps-0 That text seems ambiguous in the case of values like 'cursor: inherit' on area elements (and the possibility of future values that also take values from the parent element). In particular, the text: # has a value explicitly specified (as opposed to inheriting it # from the element's parent) seems self-contradictory regarding 'cursor: inherit'. It also seems to require (for handling cursor:inherit) that the CSS implementation expose information about whether the property was specified on the element. I don't know of other cases that require this. What Gecko does is simply do selector matching based on the document tree but then value computation as though the img element were the parent. (I think this is a similar concept to what the XBL2 spec requires in some cases, although I don't remember for sure.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] DOMTimeStamp binding
On Wed, 11 Feb 2009 10:58:00 -0800, Darin Adler da...@apple.com wrote: On Feb 11, 2009, at 10:51 AM, Kartikaya Gupta wrote: Interesting. What version did you try on? I used Chrome 1.0.154.48 and Safari 3.1 (525.13) on Windows. The relevant version is the WebKit version rather than the Safari version. They have separate version numbers. I used WebKit/525.27.1 (the version that came with Safari 3.1.1) on Mac OS X and also WebKit tip of tree on Mac OS X. I also inspected the code and saw nothing that would create an object in the JavaScript binding for this. I updated to Safari 3.2 on Windows (which looks it also has WebKit 525.27.1) and you're right, it is now showing number instead of object. I guess this was changed not too long ago. So then my question is: why was it changed? And seeing as Opera, WebKit, and Gecko are in agreement now to return a number rather than a Date in ECMAScript, will the DOM 3 Core spec be updated? Or will this get rolled into Web DOM Core and/or HTML5? Cheers, kats
Re: [whatwg] [html5] Semantic elements and spec complexity
On Tue, Feb 10, 2009 at 10:02 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 11 Nov 2004, Matthew Thomas wrote: On Wed, 10 Nov 2004, James Graham wrote: Brilliant. I'm opting out of replies to my 2004 mails though ;) -- Jens Meiert http://meiert.com/en/
[whatwg] Fwd: [html5] Semantic elements and spec complexity
(to list as well) -- Forwarded message -- From: David Gerard dger...@gmail.com Date: 2009/2/11 Subject: Re: [whatwg] [html5] Semantic elements and spec complexity To: Ian Hickson i...@hixie.ch 2009/2/10 Ian Hickson i...@hixie.ch: On Thu, 11 Nov 2004, Matthew Thomas wrote: 1. Most authors Just Don't Care about semantic markup. They'll only use it if it's the easiest way of getting the visual effect or behavior they want in their own favorite browser, or if they can use it to game search engines. (That's why authors use ul and li, for example, but not address.) I don't know if the thrust of this argument is true, but I am pretty sure the parenthetical isn't. If authors don't use address I think it's because of a variety of reasons including its poor name, and its lack of particularly useful purpose. I think there is a wide range of authoring styles, ranging from the author who really hasn't any idea that there is such a thing as semantics, and just thinks visually, to the author who just wants to get stuff done but understands that there are elements for specific purposes like lists, to the author who has bought the semantics religion but doesn't really understand it, leading to all kinds of innovative (and wrong) uses of HTML's less well known elements. This debate has come up on the Wikipedia tech lists concerning markup. HTML was intended to be a markup language usable by humans. However, the humans it was written for just happened to be Ph.D nuclear physicists. Lesser humans have a propensity to write tag soup. However, in human-writing circumstances, this is a feature rather than a bug - if it weren't, wikitext would be perfectly-formed XML rather than tag soup. So the tricky one is to write a language definition that does something meaningful with tag soup. Because tag soup is what human languages are too, and they're learned in a similar fashion (try stuff and see if it works). Think of tag-soupness as a feature, not a bug. Shudder in horror at what this implies. - d.
Re: [whatwg] [html5] Semantic elements and spec complexity
2009/2/11 David Gerard dger...@gmail.com: So the tricky one is to write a language definition that does something meaningful with tag soup. Because tag soup is what human languages are too, and they're learned in a similar fashion (try stuff and see if it works). Oh - and the way MediaWiki (the engine Wikipedia uses) deals with this is: there *is* no language definition - it's a series of PHP regular expressions. The parser is the actual definition of wikitext. This is horrifying in both big and small detail, of course. Also, the language is provably impossible to put into EBNF form. Argh. - d.
Re: [whatwg] Fwd: [html5] Semantic elements and spec complexity
On Wed, 11 Feb 2009, David Gerard wrote: Think of tag-soupness as a feature, not a bug. Shudder in horror at what this implies. I don't think that's a particularly controversial position here. People in other mailing lists involved in the development of HTML5 might disagree. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTimeStamp binding
On Feb 11, 2009, at 12:14 PM, Kartikaya Gupta wrote: I updated to Safari 3.2 on Windows (which looks it also has WebKit 525.27.1) and you're right, it is now showing number instead of object. I guess this was changed not too long ago. So then my question is: why was it changed? No, this was not changed. I don't understand why you were getting that strange result, but WebKit has always shown number for this. I went back to old versions, including digging out a copy of Safari 2 and every version I tested yields a number. There was never any code that attempted to return anything except a number. More to the point, there's also a false premise in the specification's claim that this should be a Date. The Date class in JavaScript boils down to a double for its internal representation; I believe that's by design and not just a detail of the WebKit implementation. So the claim that a number, also a double, can't handle the entire range of DOMTimestamp, but the Date class can is probably incorrect. Maybe someone can give a specific example with details of how this would go wrong — I don’t think there is any such example. -- Darin
Re: [whatwg] Selectors Tests and :enabled
On Wed, 11 Feb 2009, fantasai wrote: Given the state of current implementations and the fact that hidden input elements do have distinct enabled and disabled states, I don't understand the reasoning behind this change. http://twitter.com/WHATWG/status/1198455588 The idea was to match Selectors. On a related note, the HTML5 spec currently defines :enabled to match a, area, and link elements, as well as any other elements that are focusable--conflicting with the Selectors spec, which defines :enabled to only apply to elements that have a corresponding disabled state. The spec text I read said An element is enabled if the user can either activate it or transfer the focus to it. An element is disabled if it could be enabled, but the user cannot presently activate it or transfer focus to it., which is what I tried to follow: http://www.w3.org/TR/css3-selectors/#UIstates http://dev.w3.org/csswg/selectors3/#UIstates I see this has now changed. I will update HTML5 in due course to match the new text in Selectors. (I'll also update my spec index to point to the dev.w3.org link instead of the /TR/ page so that I don't make this mistake again.) Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When do scripts execute? (4.3.1)
On Thu, 15 Jan 2009, Kartikaya Gupta wrote:
I have a question about when scripts execute. From my reading of section
4.3.1 it seems like if script elements are created and added to the DOM
via DOM operations, then they should NOT be marked as parser-inserted,
and should get run immediately (assuming no defer/async stuff). However,
a page that I constructed to test this (below) fails in FF, Opera, and
Safari (didn't test IE). Am I misreading the spec, or does it not
accurately reflect current behavior? I found [1] after poking through
the archives a bit, and it's somewhat related, but doesn't address this
issue directly.
div id=rNOTRUN/div
script type=text/javascript
var sn = document.createElement('script');
sn.setAttribute( 'type', 'text/javascript' );
sn.appendChild( document.createTextNode(
'document.getElementById(r).firstChild.data = PASS;' ) );
document.body.appendChild( sn );// this runs the script and sets r's
text to PASS (verifiable by alert)
sn = document.createElement( 'script' );
sn.setAttribute( 'type', 'text/javascript' );
document.body.appendChild( sn );// this *should* run an empty script
block and do nothing
// the next line should have no effect since the script already ran
sn.appendChild( document.createTextNode(
'document.getElementById(r).firstChild.data = FAIL;' ) );
// here r's text is FAIL. why?
/script
[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011561.html
On Thu, 15 Jan 2009, Boris Zbarsky wrote:
That looks like a bug in the spec to me. Empty scripts with no @src are
not executed when inserted into the DOM, and are executed if they ever
become nonempty or have their src set.
On Thu, 15 Jan 2009, Jonas Sicking wrote:
At least in the mozilla implementation, though would be interested what
other implementations do. The reason was that I wanted to support the
following usage pattern:
s = document.createElement('script');
document.body.appendChild(s);
s.src = http://foo/bar;;
Note that in IE, you can set the src attribute any number of times and
every time it will download and execute the new script, even when the
old src value is the same as the new.
I've updated the spec to work like Boris describes. The browsers aren't
all exactly the same, but this seems like the most consistent set of
requirements that matches the most browsers.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issues concerning the base element and xml:base
On Fri, 16 Jan 2009, Anne van Kesteren wrote: On Fri, 16 Jan 2009 05:15:41 +0100, Ian Hickson i...@hixie.ch wrote: For external resource links created with the link element, the URL is resolved when the resource is fetched, which can be delayed if the resource doesn't apply yet (e.g. because a media query doesn't yet match). This could lead to situations where different user agents had compliant behavior, unfortunately, but this is one case where I can't see how to avoid it without requiring suboptimal behavior. You have the same scenario for inline style elements that are either in alternate state or are of a medium that currently does not apply to the document. The user agent is not required to parse those CSS blocks directly, I believe. Right. On Fri, 16 Jan 2009, Jonas Sicking wrote: Out of curiosity, why make exceptions for hyperlinks here and the cite attribute here? As opposed to for example images and iframes? Because the don't do anything special behavior (not caching the absolute URL or anything like that) leads to the following scenario: user hovers over link UA resolves URL for display script changes the base URL user clicks link UA resolves URL differently for navigation ...leading to the UI not matching what the UA actually does unless the UI is updated when the base URL changes. It's only a should though, because well, if you want your UI to be out of date, it's not critical. I can make it a may if you think should is too strong. I don't care much either way. I think I'd prefer it more strongly for the 'cite' attribute. Well the spec says If the absolute URL identified by the cite attribute is being shown to the user, or if any data derived from that URL is affecting the display, which basically means that for most browsers there's no issue here, no? On Sat, 17 Jan 2009, Calogero Alex Baldacchino wrote: I understand. Perhaps, if a main (more diffused) behaviour could be isolated, it might be chosen to normalize newer UAs behaviours, while possibly breaking fewer existing pages (the same eventually behaving differently in different browsers). However, I guess this might require a convergence between HTML and CSS specifications for this purpose (it might rise an issue on consistence for @import rules, for instance, which are in CSS scope). I don't know if it may work something like establishing that a URL, in this case, is resolved any times it is explicitly set (e.g. when the document is parsed and when the href value changes), as if the resources were immediately fetched (thus, not being affected by a successive change in a base) but not constraining UAs to do so (an inline style element might be treated as an external resource being yet fetched, thus it would be about to associate it with a base URI being valid at the moment the style was created and maintained valid until the style content is explicitely changed). Though, I guess this should be somehow consistent with existing UAs and pages (or, at least, with a significant group). I don't really follow. if you are proposing a change to the spec, could you elaborate on what exactly the change you propose is? Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposed additions to ClientInformation interface
On Sat, 17 Jan 2009, Mark Finkle wrote: On Mon, Jul 21, 2008 at 10:10 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Jul 2008, Mark Finkle wrote: The only reason I can see for such an API is to get the user's permission to use features that _may_ be a bit of a security risk to normal webapps. Clipboard, dock badging, local file drag-n-drop, even offline cache are some examples. Clipboard, drag and drop, and offline caching are all available to all applications in HTML5, since the APIs are intended to be designed in a way that doesn't expose the user to risk that requires user permission. Then why would a button be needed to activate standalone mode? What is the actual webapp doing differently? Shouldn't the webapp be acting the exact same? Sounds like it's the UA that would act differently. In standalone mode, a Web application can pretend to be a Web browser, tricking the user into thinking they are visiting a site they are not in fact visiting, and thus executing a remarkably authentic-looking phishing attack. That is why it needs an explicit opt-in. Dock badging could be equally made available safely, IMHO. The main reason I haven't made dock badging available so far is that it doesn't really make sense for most environments -- in fact as far as I know only Mac OS X has this feature. Great to know. Prism has code that allows menu and command elements to be used to add menuitems to the Dock (Trayicon on Windows) menu as well. We could even support something like menu type=icon.../menu for this too. Ignored by UAs that don't support it. Yes, this is one of the things I'm interested in exploring once menu and command (as specified today) are implemented. (Another is introducing a command= attribute to make it possible to define command state once and have UI widgets reflect that state automatically.) I am suggesting that an explicit push to make a standalone app button isn't needed. Any webapp is already able to run standalone. _If_ there is some reason, for security or code privilege, that an explicit action or confirmation is needed on the part of the user, such confirmation should be enforced at the point of execution, when the user attempts to do something that might be dangerous. It's unclear how that would work. Confirmations in general are known to not work, for instance (users click through anything). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTimeStamp binding
On Wed, 11 Feb 2009 21:14:44 +0100, Kartikaya Gupta lists.weba...@stakface.com wrote: I updated to Safari 3.2 on Windows (which looks it also has WebKit 525.27.1) and you're right, it is now showing number instead of object. I guess this was changed not too long ago. So then my question is: why was it changed? And seeing as Opera, WebKit, and Gecko are in agreement now to return a number rather than a Date in ECMAScript, will the DOM 3 Core spec be updated? Or will this get rolled into Web DOM Core and/or HTML5? Right now Web DOM Core says: A DOMTimeStamp represents a number of milliseconds. typedef unsigned long long DOMTimeStamp; ...and then refers to WebIDL for what that means to ECMAScript. -- Simon Pieters Opera Software
Re: [whatwg] HTML 5 : Misconceptions Documented
On Sun, 18 Jan 2009, Garrett Smith wrote: What do IE6, IE7 and IE8 do? I only tested IE8 and IE8's IE7 compatibility mode, and I don't recall exactly what the results were, but they were taken into account when writing the spec here. (In particular, IE doesn't distinguish between the form and its .elements array, which doesn't match HTML5 or DOM2 HTML.) In all browsers, if the control is referenced as:- document.forms[0].elements.b; - the leak does not occur. In IE, the above and document.forms[0].b ...are exactly the same. What is the reason for introducing the past names map behavior to the form? Compatibility with a legacy IE bug required (acording to Safari and Firefox devs) by legacy content. If I understand what you're saying, you are taking advice on what IE does from Safari and Firefox devs. Was there a test? I take advice on what the spec should say from everyone. I test things independently also. I posted an earlier example simple-leak-form-input.html that showed how in IE, removing a control from the document removes the property from a form. This is generally what you want. You don't want the browser to leak form controls. The past names map is not even defined as an interface; it's a euphamism for a bug. Unfortunately, as with many weird behaviors on the Web platform, it is a bug that is required for compatibility with legacy content. The idea of HTML5 is to make sure that a browser that implements all of HTML5 is compatible with legacy content. This is one of the things that legacy content requires, so the spec has to require it too. I think I understand this position. HTML5 wants to add new functionality without breaking any existing functionality. That is a good goal, and an important one if it is to be accepted. OTOH, the legacy behavior is buggy and inconsistent. It's also been replaced by a much better feature (the elements collection). You've not attempted to refute any of that; on the contrary, I see the spec includes a 'past names map' and since you've not provided any evidence, the should not be used. It is practical to deprecate it. I don't really understand what you mean here. I'm not deprecating anything in HTML5. Things are either allowed or not allowed (obsolete). With scripting, I've erred on the side of not obsoleting things, since there doesn't seem much point in doing so, especially for such minor non-features as this. There are plenty of useless/bad things browsers do. For example, accessing a named form directly off the document, as document.formName, or standardizing the way an identifier matching an element ID is resolved to that element. html body div id=a.../div script //[1] var a; alert(typeof a); /script /body /html Result: elerts object If [1] is uncommented, results vary between browsers and versions. This quirk was a problem not too long ago for the Google Code developers. It was filed as a Webkit bug that got fixed. HTML5 covers this case, IIRC. There are other things that could be standardized, such as quirks mode, String.prototype.anchor(surl), or any number of things that have better alternatives. Quirks mode is in HTML5. The String prototype is an ECMAScript issue and is out of scope here. The idea is to make it so that browsers don't feel forced to add _any_ non-standard behavior (other than experimental innovations using vendor- prefixed names and stuff). HTML5 does make distinctions for legacy content in some places, but not with this behavior. It would be a good idea to make a clear distinction that accessing form controls directly off the form is legacy content. Why? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Script/parser interaction bug?
On Tue, 20 Jan 2009, Kartikaya Gupta wrote:
I have a test case that works in major browsers (FF, Opera, Safari, IE6)
but that I don't think would work if the they followed the behavior as
currently specified in HTML5. I've put the test case online:
http://stakface.com/pub/mango/ext7.html
The assertion document.getElementById('r').firstChild.data == 'PASS'
is true after the page has loaded, whereas according to the spec I don't
think it shouldn't be.
The steps are roughly as follows:
- tokenize/treebuild ext7.html until the first closing script tag is found
(for the 7a.js script)
- run the script. this sets 7a.js to be the pending external script
- execute the pending external script (7a.js) since it's not a re-entrant
invocation of the tree builder
--- insert the 7b.js line into the input stream
--- tokenize/treebuild the 7b.js script tag until the /script for 7b.js is
found
--- run the script. this sets 7b.js to be the pending external script
--- now, since there is a pending external script and this is a re-entrant
invocation, set the pause flag to true and bail
--- insert the other stuff in 7a.js into the input stream
--- since the parser pause flag is set this other stuff does NOT get
tokenized/treebuilt yet
- 7a.js finishes executing, and now we have a new pending external script,
which is 7b.js
I think the parser pause flag gets set to false again here.
- execute 7b.js
--- throws
- continue processing input stream (this now has the contents of the
document.write calls from 7a.js, line 2 onwards)
- tokenize/treebuild the input stream until the /script that was
document.write'd at the bottom of 7a.js is encountered
- execute the script
--- insert the div into the input stream
--- since the parser pause flag is still set the div does NOT get
tokenized/treebuilt
Why is it still set?
--- run the line that sets .firstChild.data to PASS. since the div isn't in
the DOM yet, this throws and the script is done
- unwind back to the treebuilder, which clears the parser pause flag since
the script nesting level drops to zero
- tokenize/treebuild the input stream, which contains the div tag
- add div with content FAIL to the DOM
- done
Here, I think the pause flag needs to get cleared earlier, so that when
the div is inserted into the input stream, it gets tokenized and added
to the DOM. This would make the behavior consistent with what I'm seeing
in major browsers. Thoughts?
Could you reannotate the above but with the script nesting level
explicitly given at each step?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] defer on style, depends
On Mon, Feb 9, 2009 at 7:37 PM, Boris Zbarsky bzbar...@mit.edu wrote: Garrett Smith wrote: In general, I want better declarative control over loading external resources. The solution(s) should not cause compatibility problems with existing browsers (because I have to support IE6 and Firefox 2). Honestly, by the time anything we're discussing now will be shipping in a browser Firefox 2 marketshare should be nonexistent. I can't speak for IE6. I'm optimistic. We can make it so authors can declare that (a) script/s will not wait for (a) stylesheet? Or declare that a script will wait for a particular stylesheet (which is something that happens already). I want the browser to be able to load and run a script without being in the position of trying to determine if it should wait for stylesheet data to complete. As in you don't want the browser to make this determination, right? That is, you know that your script doesn't depend on any style data and you want the browser to just run it? In one case, yes. I would be fine with a way to flag scripts with that information, though there is a catch-22: if you flag such a script and it DOES depend on style information, then existing UAs will get it right and any UA implementing the new spec will get it wrong. If the page does what it is designed to do, and that the design is flawed, the page would be broken by design. Designing things to be broken would be wrong. Of course the same is true for the flag-the-stylesheet proposal... In browsers that do support defer, the script would run *after* the document parsed, and that would occur after the stylesheet loaded. I'm not sure why this is a performance problem, per se. 2) want to load stylesheets later, (infoPanel example) Not sure what this example is, or why this is insufficienty served by, say, putting the link at the end of the HTML (assuming HTML allowed that, of course). Are you proposing HTML allow that? That's one possible solution to the issue of starting stylesheet loads as late as possible, yes. It's not a great one a priori, but has the benefit of good compat with existing UAs (which you said was a priority for you). Not that I think you are wrong, but that statement ought to be backed up by some tests. The script could declare whether it needs such resource by its depends= attribute. However, browsers today delay (some) scripts from running. Scripts depend on stylesheets; content depends on scripts and stylesheets. Content can contain more scripts. Omitting depends for scripts could not possibly solve the problem for browsers today (because they already depend on stylesheets). Honestly, I don't think anything would solve the problem for browsers _today_. No, just observing that the problem could have been avoided with a depends= attribute, if only such attribute had existed c2000, and having scripts wait only when depends is set. I like this design. An independent attribute on a link says that a browser does not need to wait for that resource to finish loading before it loads other resources (like loading a script). When the parser parses that independent attribute, it sets a flag for the browser go ahead and download and run any subsequent script. That doesn't work for today's browsers, though, just like flagging the script doesn't. Or am I missing something? You got it. It doesn't work for today's browsers. However, it isn't guaranteed *not* to work by any standard. In fact, browsers behave differently on the matter. Could this new feature result in breaking code in older browsers? Those browsers would load and apply the stylesheet in series. That would be slower. A race condition is where the script might run before the sheet loaded. Developers who don't know that shouldn't use that feature. The sad path -- what can happen when a developer misuses independent: Case 1: Developer tests in the browser that supports independent. The script runs before the stylesheet loads in browsers that support independent. The result of the race condition is what the developer wants. The opposite effect happens in older browser. Case 2: The author uses independent and only tests in browsers that do not support that feature. When loaded in a newer browser that does support independent, the script loads before the stylesheet and the page does not work as designed. The problems in case 1 or case 2 could happen today. Browsers today are inconsistent with waiting for stylesheets to download (try any of the examples I have provided in Opera, Safari, Firefox, IE). Developers today blame the browser, or possibly the script when it doesn't work. The happy path: The defer on link and depends on script work together. The link is deferred, then loaded when the script loads. A nodepends type attribute on a script would work, too. I like that idea, though it does mean the browser has to do some lookahead (then again, apparently they already do). What
