Re: [whatwg] Adding "ipfs" to the safelisted schemes
On Saturday 2018-07-14 21:37 +0200, Mathias Rangel Wulff wrote: > Hi Domenic > > Thank you for getting back to me. > > > Without implementer interest, there's not much we can do on the spec > side. > > Is it correctly understood that with "implementers" you refer to the team > behind each browser implementation? Firefox whitelisted "ipfs" as a safe > scheme in January 2018: > https://hg.mozilla.org/mozilla-central/rev/c2cb8a06bcf1 I believe this is a different whitelist, related to Web Extensions. I think the actual list Firefox uses for registerProtocolHandler is based on the following set of preferences: https://searchfox.org/mozilla-central/search?q=network.protocol-handler.external= by the implementation which I believe lives here: https://searchfox.org/mozilla-central/source/browser/components/feeds/WebContentConverter.js -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Monday 2015-03-09 16:52 -0700, Tab Atkins Jr. wrote: That's a good question. I suspect that .naturalWidth/Height should return the image's dimensions before applying CSS rotations. This is likely to be surprising, but also probably the correct answer for separation-of-concerns reasons. I wonder whether I need to tweak Images, or Hixie needs tweak img. Hmm. I really think that the mechanism for opting in to honoring EXIF should make the browser act as though the rotation were in the image format. It's a compatibility hack (because implementations were initially shipping without EXIF support, and there may be a dependency on that), but once the developer has opted in, everything should really act like the rotation is part of the image format. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] [cssom-view][css3-animations] Sync events with requestAnimationFrame
On Tuesday 2014-12-09 11:00 +0100, Simon Pieters wrote: HTML is invoking a hook that does not yet exist. [[ For each fully active Document in docs, run CSS animations and send events for that Document, passing in now as the timestamp. [CSSANIMATIONS] ]] To be honest, I'm somewhat skeptical that the order and manner in which the HTML spec invokes those hooks is correct (mainly because it has very little resemblance to what we actually do in our implementation), but figuring out what I think should be there instead is a rather large task. My concerns about https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 are largely related to: (1) Some of the steps in the Update the rendering list also need to be done when certain things are flushed (e.g., evaluating media query changes), in addition to during a refresh tick (items 8.4 - 8.10). (Maybe this is specified elsewhere, though?) (2) The relative ordering needs to be handled more carefully. In particular, the refresh tick (8.4 - 8.10) has to: a. do things that might update specified style b. run event handlers c. flush style and layout in order to render Items in (b) might flush style and layout from script; this means that in general the things in (a) should all be done before the event handlers in (b), so that they're seeing current style data *if they happen to flush*. Items in (b) are also allowed to update current style data; this can lead to interleaving of setting style and flushing it, but that's unavoidable, and putting (b) before (a) doesn't improve this. In other words, the animations should all tick their notion of current style first, so that event handlers resulting from the refresh tick get current style data rather than style data resulting from the previous refresh tick. If animations are the only thing that can do both (a) and (b) then it's possible for animations to have a single hook. (In our implementation I think that might be the case, since we don't update media queries as part of the refresh timer handling... although perhaps something related to scrolling means that isn't the case anymore.) This definitely requires that the run CSS animations and send events be before the 3 steps that currently precede it (run the resize steps, run the scroll steps, and evaluate media queries and report changes), since the hooks in those steps appear to only fire events and not post style changes. But I suspect it requires bigger changes to the spec's model as well. (3) Also, the work should happen for both CSS Animations and CSS Transitions. (This one is minor.) As I said, though, figuring out how I'd want the spec to address (1) and (2) is a rather large task; it requires carefully looking at the other things that interact with these things. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
On Thursday 2014-11-06 12:36 -0800, Daniel Holbert wrote: Should these coordinates be relative to... (A) ...the top-left corner of the img element itself? OR (B) ...the top-left corner of the rectangle where the image's pixel data actually maps to? (which may be inside or outside the bounds of the img element) (Of course, parts outside the img won't render and shouldn't receive clicks, but the rect is still there.) I tend to think B is the correct answer, but I'm not 100% sure, and I'd like a sanity-check. I also think it should be (B), since the meaning of the coordinates in the imagemap shouldn't change as a result of CSS styling of the image. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] Maximum value needed for tabindex
On Friday 2014-07-25 00:19 +0200, Charles McCathie Nevile wrote: Having 32k items in a page doesn't seem like the real-world problem would be numbering the tabindex, but the fact that there are 32k active things you're trying to manage in a single ordered list… Having a notion of scoping for tabindex (and 'nav-index') would be great. It's been proposed a number of times, e.g.: http://lists.w3.org/Archives/Public/wai-xtech/2011Nov/thread.html#msg35 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033775.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-August/007236.html I'd be happy to see somebody drive a solution to this forward. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] Proposal: Event.creationTime
On Tuesday 2014-05-06 23:00 -0700, Adam Barth wrote: Can we just change timeStamp to be a DOMHighResTimeStamp rather than introducing a redundant property? I'd certainly be happy to see such a change; I argued that Event.timeStamp be based on a monotonic clock previously, in: http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0071.html http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0098.html I'm not sure if there would be compatibility problems from changing from unsigned long long [1] to double [2], though. The type change seems like the biggest compatibility risk in content that works today across browsers, given that browsers on whether the time is epoch-based or monotonic. I don't have any data on how or how often Event.timeStamp is used, though. -David [1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-DOMTimeStamp [2] http://www.w3.org/TR/hr-time/#sec-DOMHighResTimeStamp -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
[ resending this message, originally dated Date: Tue, 29 Apr 2014
11:42:10 -0700, since I just noticed it didn't make it through to
the list due to the list's content-type filters rejecting signed
messages ]
On Tuesday 2014-04-29 17:55 +, Ian Hickson wrote:
On Wed, 29 Jan 2014, Tab Atkins Jr. wrote:
We talked this over in the CSSWG meeting, and came up with a proposal
for non-magical styling that is still very close to current behavior in
all browsers:
br {
display-box: contents;
content: \A;
white-space: pre;
}
I've filed a bug to track this. It would be useful if browser vendors
could indicate whether they think Tab's proposal is satisfactory (in
particular, is 'display-box' something that browsers will implement?
Apparently Gecko is doing it, anyone else?).
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503
I might not want to implement br this way, since display-box:
contents involves a bit of complexity that I wouldn't want to impose
on such a common element. Then again, we could perhaps special-case
br inside the implementation of display-box: contents. But it's
not just a trivial matter of removing the existing br
implementation and replacing it with the above.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
On Wednesday 2013-05-01 01:01 -0700, Elliott Sprehn wrote: On Wed, Apr 24, 2013 at 9:22 AM, Peter Occil pocci...@gmail.com wrote: I have no objection to the name baseLang rather than language as the name of the DOM attribute. But if there isn't more interest or you decide not to add this DOM attribute, I encourage you to at least: fwiw WebKit (and Blink) implement this through CSS inheritance since you need to know the lang for all kinds of things and walking up the DOM repeatedly would be expensive. -webkit-locale is inherited by default and contains the enclosing @lang value. You can query it through getComputedStyle(node).webkitLocale. That doesn't help your custom parser though. In Gecko it's also implemented through CSS inheritance, but it's not exposed to Web content as a CSS property. (Internally it's '-x-lang', but that name isn't exposed.) We use the language for: * font selection * language-specific text-transform behavior * hyphenation (which doesn't work unless it's explicitly specified, as required by http://dev.w3.org/csswg/css-text/#hyphens-property ) -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] [html5] r7749 - [giow] (3) make ruby reset text-indent for sanity's sake (like with table) Fix [...]
On Wednesday 2013-03-13 16:29 -0700, wha...@whatwg.org wrote:
Author: ianh
Date: 2013-03-13 16:29:56 -0700 (Wed, 13 Mar 2013)
New Revision: 7749
Modified:
complete.html
index
source
Log:
[giow] (3) make ruby reset text-indent for sanity's sake (like with table)
Fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=20709
Affected topics: Rendering
-ruby { display: ruby; }
+ruby { display: ruby; text-indent: initial; }
This change seems like a workaround for an implementation bug rather
than something that belongs in the spec. The text-indent property
applies only to block containers, which display:ruby is not.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] scoped style sheets and @-rules
On Sunday 2013-02-17 11:35 -0600, Glenn Maynard wrote:
On Mon, Jan 21, 2013 at 8:39 AM, L. David Baron dba...@dbaron.org wrote:
But I think it's a large amount of extra implementation complexity
to honor @-rules whose purpose is to build global dictionaries (in
particular, @keyframes and @font-face), and I suspect the end result
of honoring them would yield technology that's more confusing for
authors. Anything that can be done by changing the meaning of an
@keyframes or @font-face rule within a subtree could also be done by
declaring a different animation rule or font-family within that
subtree. I suspect the extra clarity from the latter makes it a
better authoring practice anyway, so I don't think implementations
should be required to add support for a feature that it's better to
not use.
You could make the same argument against most of @scoped: you don't need to
define a scoped style for a class, just use a different class name.
I think for the rest of @scoped, there are both significant
performance and encapsulation advantages.
It seems more likely that you'd want to use this for font-faces or
keyframes so that you can be sure the name won't collide. For example, a
templating system might output
div
style scoped
@font-face { font-family: font; src: url(font.ttf); }
/style
span style=font-family: font;content/span
/div
where the font URL is dynamically generated and the span is entered by the
user, who's been told that the font-family font will be defined to
something. The template doesn't need to worry about colliding with a
font-family by that name elsewhere (including other instances of the same
template or elsewhere in the document).
I don't know about implementation complexity (though I don't know why
creating a stack of font-face dictionaries would be any more complex than
creating a stack of style rules), but I don't think this is any more
complex for authors than the rest of @scoped.
One of the big problems with @font-face is that it's not obvious
whether the @font-face rules should be scoped to:
1. font-family declarations in the scoped style sheet, or
2. elements in the style sheet's scope, whether the declarations
came from the scoped style sheet or not
(The HTML spec currently says (2), but I think used to say (1).)
Option (1) adds a huge amount of implementation complexity; it
requires the CSS cascading process, at least for font-family, to
carry around information about where the declarations came from.
Option (2) is more reasonably implementable, but I'm not sure it's
what authors expect. In particular, it implies changes to fonts
that are inherited in from outside the scoped style sheet. It's not
clear to me that this behavior is useful enough to authors to be
worth the (still not insubstantial) work of implementing it.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] scoped style sheets and @-rules
On Monday 2013-01-21 11:17 -0800, Tab Atkins Jr. wrote: On Mon, Jan 21, 2013 at 6:39 AM, L. David Baron dba...@dbaron.org wrote: Thus I think the specification should mandate that @keyframes and @font-face are ignored in scoped style sheets, just like @page. I think it would also be good if the specification left the effects of unknown @-rules undefined until whether they should be supported can be properly considered. Should we ignore them entirely, or just ignore the scoped-ness and have them fill in the global dictionary? I prefer ignoring them entirely, since authors will notice if things aren't working as expected. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
[whatwg] comments on 'position: absolute-anchored'
A few comments on the 'position: absolute-anchored': http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#css-position-absolute-anchored (1) The interaction with CSS transforms is different from the interaction that 'position: fixed' has. Is that intentional? (Elements with a CSS transform establish a containing block for position:fixed elements.) If it is intentional, are implementors really ok with that (given the desire to be able to do things like animate transforms on another thread, and interactions with things like z-ordering rules)? (2) I think it's unacceptable to have a computed value that's not specifiable in CSS; it breaks basic ideas of round-tripping and the CSS OM. (3) Is there a way to get notified when new CSS features are added to the HTML spec? I only happened to stumble across this one. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
[whatwg] scoped style sheets and @-rules
I thought I'd brought this issue up before, but I can't seem to find a record of it. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-style-scoped currently says that, inside scoped style sheets, @page rules are ignored, but other @-rules are honored, scoped either to the style sheet or to the subtree. I think it makes perfect sense to honor @-rules whose effects are scoped to the style sheet (@namespace, also @charset if it weren't already ignored) or @-rules whose effects are to condition the rules inside of them (all the rules in css3-conditional: @media, @supports) or import more rules (@import). But I think it's a large amount of extra implementation complexity to honor @-rules whose purpose is to build global dictionaries (in particular, @keyframes and @font-face), and I suspect the end result of honoring them would yield technology that's more confusing for authors. Anything that can be done by changing the meaning of an @keyframes or @font-face rule within a subtree could also be done by declaring a different animation rule or font-family within that subtree. I suspect the extra clarity from the latter makes it a better authoring practice anyway, so I don't think implementations should be required to add support for a feature that it's better to not use. Thus I think the specification should mandate that @keyframes and @font-face are ignored in scoped style sheets, just like @page. I think it would also be good if the specification left the effects of unknown @-rules undefined until whether they should be supported can be properly considered. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Implementation issue: step mismatch handling for input type=range
On Thursday 2013-01-17 20:13 +, Ian Hickson wrote: On Thu, 17 Jan 2013, Jonathan Watt wrote: If the step base considered the 'minimum' instead of the 'min' content attribute, then the step base would be zero, and thus the value would settle at zero. Right, but that would be highly unlikely to make sense, because it would mean the value the author set was an invalid value. You shouldn't be forced to specify the minimum if you're already specifying a step and a value and the default minimum of zero is adequate. That still seems like a surprising behavior (and it entirely disables step constraints in a peculiar set of cases). It would seem better to either: * infer the step base from the minimum whenever there is a minimum, or * when inferring the step base from the default value (the value content attribute), apply the minimum and maximum to the default value -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] menu and friends
On Friday 2013-01-04 16:52 -0800, Jonas Sicking wrote: On Fri, Jan 4, 2013 at 3:34 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Dec 31, 2012 at 12:54 AM, Jonas Sicking jo...@sicking.cc wrote: What I was saying as a browser vendor is that I don't think that authors are going to use this feature unless it provide the ability to replace the existing context menu. Or at least almost entirely replace it. I don't think I can agree with this. This argument would be more believable if authors currently used pile-of-divs for context menus a lot, but I only rarely actually see it. I think this is because it's just plain *hard* to do it even half-decently. The extreme ease with which authors will be able to create high-quality context menus with menu will, I think, override a lot of the concerns. I feel that I do see this quite often. maps.google.com, Google docs, and Zimbra are three examples off the top of my head that I spend a lot of time with. Has anyone asked the authors of these sites if they would have liked to retain the browser's default context menu items if they had been able to do so (while simultaneously adding their own items)? -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
[whatwg] [Rendering] zero width attributes on table, th, td should be ignored
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#tables says: # The table element's width attribute maps to the dimension # property 'width' on the table element. ... # The td and th elements' width attributes map to the dimension # property 'width' on the element. These rules should have an extra condition to say that any zero value (be it a zero integer or a zero percentage) is ignored rather than mapping to the 'width' property. This is needed for Web-compatibility; width=0 is ignored by all major browser engines (at least for the td case, which I tested), and source-code comments in Gecko indicate this behavior is needed for compatibility. However, they're ignored at different levels in different engines. In Gecko and IE10, they're ignored at the level that I'm proposing, and 'width:0' in CSS still works. In WebKit and Opera, 'width:0' in CSS is *also* ignored, presumably at the table layout level. Given the engine split here, I believe it's better to have the weird behavior be more limited, and I'd prefer to see the ignoring be specified at the HTML level so that CSS behaves without this discontinuity. My tests are as follows: http://dbaron.org/css/test/2013/cell-width-zero/cell-width-zero-standards-html http://dbaron.org/css/test/2013/cell-width-zero/cell-width-zero-quirks-html This pair of tests demonstrate that the HTML width=0 is ignored in all engines, and the first cell is slightly wider than the second. http://dbaron.org/css/test/2013/cell-width-zero/cell-width-one-standards-html http://dbaron.org/css/test/2013/cell-width-zero/cell-width-one-quirks-html This pair of tests demonstrate that HTML width=1 works in all engines, and forces the first cell to its minimum intrinsic width. http://dbaron.org/css/test/2013/cell-width-zero/cell-width-zero-standards-css http://dbaron.org/css/test/2013/cell-width-zero/cell-width-zero-quirks-css This pair of tests shows differing behaviors between browsers; the first cell is narrowed to its minimum intrinsic width in Gecko and IE10 (showing the behavior is at the HTML level) but not in WebKit or Opera (showing the behavior is at the CSS level). (It might be worth writing the parallel tests for table since I only tested td, and the parallel tests for percentage values since I only tested integer values.) -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Quirks Mode Standard
On Monday 2012-02-13 09:00 +0100, Simon Pieters wrote: Exactly. My proposal, again, is that neither of these quirks apply inside a shorthand. But this is not what Gecko does. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1339 I don't know how much content uses unitless lengths or hashless colors in shorthands in quirks mode. We will need to research both implementations and content to inform what the spec should say here, I think. To be exact, they don't apply inside the following shorthands: -moz-border-end -moz-border-start -moz-columns background border border-bottom border-image border-left border-right border-top the size/weight/style and family parts of 'font' list-style outline and also don't apply inside the following complex properties: box-shadow text-shadow I suspect that the bit that was documenting an exception for font-size was documenting the exception (that the quirk *does* apply) for *within* the 'font' shorthand. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Quirks Mode Standard
On Monday 2012-02-13 14:03 +0100, Simon Pieters wrote: You say that it doesn't apply for the size of 'font'. The link above uses font:60 serif and has a 60px font size in Firefox Nightly for me. These also get applied: font:101 serif font:100 60 serif font:100 100 serif font:bold 100 serif font:normal normal normal 100 serif These don't: font:100 serif font:100/1 serif font:normal 100 serif font:normal normal 100 serif I believe they don't because the '100' gets consumed as a valid value of font-weight (since the shorthand parser assumes there's no ambiguity to be handled between font-weight and font-size), and then the shorthand is syntactically invalid because it doesn't have a font-size. I don't see any reason to fix that. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Quirks Mode Standard
On Friday 2012-02-10 10:37 -0500, Boris Zbarsky wrote: I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. For the record, Gecko doesn't implement any CSS keywords or units that contain only the characters a-f (treating any -moz- prefixes as not present). However, if I double the search range to a-l, then Gecko implements the following units: ch deg and the following keywords: all cell deck field fill hide So I don't think it's an unrealistic worry that we might have some such keywords in the future. (Consider, for example, 'fade'.) More importantly, though, if Gecko encounters an ambiguity between color and keyword in a property that accepts both, it will pick the keyword. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Quirks Mode Standard
On Thursday 2012-02-09 15:51 +0100, Simon Pieters wrote: Today I started working on a spec for quirks mode. I used https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior as a starting point. The draft is here: http://simon.html5.org/specs/quirks-mode I'd note that the item All of the style rules in layout/style/quirk.css apply. probably needs to be expanded, and items analyzed individually. It is very likely that more quirks need to be added, but as I went through the list I was surprised about how many of them were *not* widely implemented across browsers, and so may not be needed for Web compat and can be dropped. I'm happy for the spec to be moved somewhere, and I can volunteer to edit it, but I can't promise to spend a lot of time on it. It would be useful if browser implementors could review the draft, consider dropping quirks, give feedback about quirks that can't be dropped, and consider aligning with other implementations for quirks that are here to stay. I'd note that there are sometimes messy interactions between behaviors. For example, if my memory is correct, implementing the HTML5 parsing algorithm required that we implement a text-decoration quirk that we previously didn't have (but WebKit did), as described in https://bugzilla.mozilla.org/show_bug.cgi?id=572713 . (Speaking of which, I'm curious why that quirk, on propagation of text-decoration into tables, didn't make it from the developer.mozilla.org URL you gave into your document. That makes me think the document isn't quite ready for review yet.) There may be cases where only some browsers have a described quirk, but other browsers have a different behavior that provides the same compatibility. That said, I agree it's likely that many of the quirks can be removed. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Encodings and the web
On Tuesday 2011-12-20 12:01 +0100, Anne van Kesteren wrote: If you are interested in helping out testing (and reverse engineering) multi-octet encodings please let me know. Any other input is much appreciated as well. This seems like one of those areas where it may be substantially easier to figure out what implementations do by looking at their code than by reverse-engineering, at least for the implementations whose code is available publicly. Gecko's code lives in http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ . There are others who know it substantially better, but I or others could probably answer questions you have about how it works and how to understand it. I'm not the right person for pointers to other implementations, though. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
[whatwg] Unicode as alias for UTF-16 (was Re: Default encoding to UTF-8?)
On Monday 2011-12-19 17:17 +0200, Henri Sivonen wrote: On Sun, Dec 11, 2011 at 1:21 PM, Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no wrote: I discovered that UNICODE is used as alias for UTF-16 in IE and Webkit. ... Seemingly, this has not affected Firefox users too much. It surprises me greatly that Gecko doesn't treat unicode as an alias for utf-16. Why? If it's not needed, why shouldn't WebKit and IE drop it? -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Default encoding to UTF-8?
On Wednesday 2011-11-30 15:28 -0800, Faruk Ates wrote: My understanding is that all browsers* default to Western Latin (ISO-8859-1) encoding by default (for Western-world downloads/OSes) due to legacy content on the web. But how relevant is that still today? Has any browser done any recent research into the need for this? The default varies by localization (and within that potentially by platform), and unfortunately that variation does matter. You can see Firefox's defaults here: http://mxr.mozilla.org/l10n-mozilla-beta/search?string=intl.charset.default (The localization and platform are part of the filename.) I changed my Firefox from the ISO-8859-1 default to UTF-8 years ago (by changing the intl.charset.default preference), and I do see a decent amount of broken content as a result (maybe I encounter a new broken page once a week? -- though substantially more often if I'm looking at non-English pages because of travel). I'm wondering if it might not be good to start encouraging defaulting to UTF-8, and only fallback to Western Latin if it is detected that the content is very old / served by old infrastructure or servers, etc. And of course if the content is served with an explicit encoding of Western Latin. The more complex the rules, the harder they are for authors to understand / debug. I wouldn't want to create rules like those. I would, however, like to see movement towards defaulting to UTF-8: the current situation makes the Web less world-wide because pages that work for one user don't work for another. I'm just not quite sure how to get from here to there, though, since such changes are likely to make users experience broken content. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Default encoding to UTF-8?
On Thursday 2011-12-01 14:37 +0900, Mark Callow wrote: On 01/12/2011 11:29, L. David Baron wrote: The default varies by localization (and within that potentially by platform), and unfortunately that variation does matter. In my experience this is what causes most of the breakage. It leads people to create pages that do not specify the charset encoding. The page works fine in the creator's locale but shows mojibake (garbage characters) for anyone in a different locale. If the default was ASCII everywhere then all authors would see mojibake, unless it really was an ASCII-only page, which would force them to set the charset encoding correctly. Sure, if the default were consistent everywhere we'd be fine. If we have a choice in what that default is, UTF-8 is probably a good choice unless there's some advantage to another one. But nobody's figured out how to get from here to there. (I think this is legacy from the pre-Unicode days, when the browser simply displayed Web pages using to the system character set, which led to a legacy of incompatible Web pages in different parts of the world.) -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] WHATWG on Google+
On Monday 2011-11-21 20:26 +, Ian Hickson wrote: On Mon, 21 Nov 2011, Boris Zbarsky wrote: What's needed is a way to notice when changes to a particular piece happen. There isn't one. Which pieces do you _not_ want to be notified of changes to? I currently (try to) mark all changes that affect browser vendors as such in the checkin comment (as opposed to, e.g., editorial changes or changes that only affect authors and conformance checkers), but if there is some other categorisation scheme for the checkins that would be more helpful, I can definitely try a different mechanism. I have tried to use these markings to filter changes; however, my sense was that a majority of those marked as g didn't actually require Gecko changes. I think that's because you often mark things as affecting browsers simply because the browsers implement that section of the spec. But it doesn't follow from that that the browsers need to change, if the spec change is in an area where the spec is being modeled on the browsers (i.e., further specification of existing behavior required for Web compatibility) rather than the browsers being modeled on the spec. This seems more of a problem in in areas where the browsers are closer to each other than the spec is to them, since in those cases the spec changes are least likely to require changes from the browsers. When they do require Gecko changes, it's also often hard for me to figure out if some Gecko developer needs to be notified or if that developer is the person who requested the change in the first place. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
On Friday 2011-04-08 13:54 -0700, Tab Atkins Jr. wrote: This doesn't match Webkit's behavior. Instead of steps 5 and 6, we just try to parse it as a CSS color. As I pointed out in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026449.html this isn't compatible with doing the following simultaneously: * using the algorithm given, which converts the values to colors at parse time * correctly handling dynamic changes of system appearance for the system color values Correctly handling dynamic changes of system appearance here would be a significant amount of work even if the algorithm here changed, and I'd really rather not add that support for a legacy feature, nor would I like to have an inconsistency between CSS and HTML as to whether system colors are dynamically updated. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla Corporation http://www.mozilla.com/ 턂
Re: [whatwg] navigation shouldn't abort if canceled
On Wednesday 2011-02-02 20:41 +, Ashley Sheridan wrote: For the links to open a new web page that would actually be handled by an external app. I remember a few years back when Yahoo! Messenger came with such an app that set itself up as your default mail program and opened a new window. It would be obvious it was a separate app if you clicked on the mailto link on a secondary browser that wasn't the system default. I don't know if webmail clients handle things differently. Does this behaviour ever happen without the help of an external app or a plugin? Webmail clients can register themselves with the browser using registerProtocolHandler: http://whatwg.org/specs/web-apps/current-work/#custom-handlers https://developer.mozilla.org/En/DOM/Window.navigator.registerProtocolHandler Firefox also ships with some common Webmail clients pre-configured in preferences - Applications - mailto so they don't even need to bother registering themselves. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?
On Tuesday 2010-11-23 22:09 +, Philip Taylor wrote: On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Right now, canvas gradients interpolate their colors in non-premultiplied space; that is, the raw values of r, g, b, and a are interpolated independently. This has the unfortunate effect that colors darken as they transition to transparent, as transparent is defined as rgba(0,0,0,0), a transparent black. Under this scheme, the color halfway between yellow and transparent is rgba(127,127,0,.5), a partially-transparent dark yellow, rather than rgba(255,255,0,.5).* If you define the gradient as interpolating from solid yellow to transparent black, I'd expect that it *should* be semi-transparent blackish-yellow in the middle. If you want it to be pure yellow, don't use a keyword which is explicitly specified as transparent black - define the gradient from rgba(255,255,0,1) to rgba(255,255,0,0) instead. Then you'll get rgba(255,255,0,0.5) in the middle. Sure, you can solve that particular case. However, if neither of the endpoints is precisely transparent, and you're changing both color and alpha components, you'll still get an ugly effect with the current rules, and one that you can't work around. (I experimented with both methods when implementing CSS transitions of colors, and went with premultiplied. http://dbaron.org/css/test/2009/transitions/transitions-alpha makes it look like WebKit has now switched to premultiplied.) That sounds like SVG gradients *can't* be using premultiplied colours. Yes, because SVG doesn't have RGBA colors; it has RGB colors (in stop-color) and a separate stop-opacity property/attribute. So the choice doesn't apply to SVG. Maybe CSS should have originally used the keyword transparentblack instead of transparent (though the distinction didn't matter before gradients existed) - changing the gradient algorithm solely to work more intuitively when people happen to use that one particular incorrectly-named keyword seems backwards, and a mistake in CSS. It's not only the 'transparent' keyword; it affects all cases of gradients between colors with different alpha values and different color values. And in cases where one of the endpoint alphas is not 0, it's not possible to get the correct (premultiplied) result with a gradient computed in nonpremultiplied space. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Monday 2010-08-30 14:28 +0200, Anne van Kesteren wrote: On Sun, 29 Aug 2010 15:01:27 +0200, L. David Baron dba...@dbaron.org wrote: On Wednesday 2010-08-25 10:28 +0200, Anne van Kesteren wrote: We need a feature for case-insensitive matching in Selectors already for XHTML (if we really care about this, not sure we do). Allowing case-insensitive matching beyond matching of a fixed set of ASCII-only values seems scary. If such a general selectors feature were defined as ASCII-only, then it would appear to work but then break for cases where it needed to be more than ASCII-only (or where the standard ASCII-only algorithm is incorrect, such as Turkish, where where I/i are not case-equivalents; İ/i and I/ı are). If it weren't ASCII-only, it would involve significantly more complexity than what's needed to support HTML. I think it can be ASCII-only. You need it for input[type=password] and such. The only attributes that are currently compatibility caseless are name on input type=radio and name on map. But the problem with adding a new general selectors feature is that authors will discover it and try to use it for things that aren't ok being ASCII-only. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Wednesday 2010-08-25 10:28 +0200, Anne van Kesteren wrote: On Wed, 25 Aug 2010 09:44:34 +0200, Christoph Päper christoph.pae...@crissov.de wrote: I for one would expect that selector to match that element, although I would never write HTML like that. Imagine a browser or user stylesheet where you would effectively have to list all possible casings. We need a feature for case-insensitive matching in Selectors already for XHTML (if we really care about this, not sure we do). Allowing case-insensitive matching beyond matching of a fixed set of ASCII-only values seems scary. If such a general selectors feature were defined as ASCII-only, then it would appear to work but then break for cases where it needed to be more than ASCII-only (or where the standard ASCII-only algorithm is incorrect, such as Turkish, where where I/i are not case-equivalents; İ/i and I/ı are). If it weren't ASCII-only, it would involve significantly more complexity than what's needed to support HTML. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Monday 2010-08-16 15:14 -0700, wha...@whatwg.org wrote: [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers think underscores are ugly. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590 This has the disadvantage that vendor-specific features can't be commented out in a conformant way since '--' is not permitted within comments, per http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#comments I'd also note that Gecko has quite a few _moz- attributes, although they're for internal things rather than things that we intend to expose to authors. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] CSS2 system colors in legacy color values
The rules for parsing a legacy color value in http://www.whatwg.org/specs/web-apps/current-work/complete/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value specify that CSS2 system colors should be accepted, and that they should be converted to a simple color. It seems like a substantial amount of work to get dynamic change handling correct for this case, since system colors can change dynamically when the user changes system appearance. I'd really like to avoid having to add dynamic change handling for this, and I'd also like to avoid having to make system colors dynamic in CSS but static in HTML. What was the motivation for adding support for CSS2 system colors (which I would note are deprecated in css3-color) to legacy HTML color values? What implementations support them, and do they respond to dynamic changes properly? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] :checked should match selected option elements
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-checked defines what elements match the :checked pseudo-class. However, I think it's missing an important case: selected option elements within a select. http://www.w3.org/TR/css3-selectors/#checked says: # For example, the :checked pseudo-class initially applies to such # elements that have the HTML4 selected and checked attributes as # described in Section 17.2.1 of HTML4, but of course the user can # toggle off such elements in which case the :checked # pseudo-class would no longer apply. which clearly shows that it's the intent of css3-selectors that the pseudo-class apply in this case. From looking at VCS history, Gecko has implemented :checked on option elements since Gecko 1.8 == Firefox 1.5. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] Should :default apply to checkboxes, radios, and options?
For a long time, Gecko has implemented the behavior that the :default pseudo-class matches checkboxes, radios, and options that are selected by default (i.e., anything that matches :checked by default). I think supporting it for option elements is explicitly stated in the spec where :default was introduced: # One example is the default submit button among a set of buttons. # Another example is the default option from a popup menu. # Multiple elements in a select-many group could have multiple # :default elements, like a selection of pizza toppings for # example. -- http://www.w3.org/TR/css3-ui/#pseudo-default and I think supporting it for radios and checkboxes logically follows from that. However, the HTML5 spec says that :default should not apply in these cases: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-default I don't feel particularly strongly about this one, but it seems like the original intent of :default was to match both things that are the default button and things that are selected by default. Was this difference with existing implementation behavior intentional? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] definition of :link and :visited should allow flexibility
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-link says: # All a elements that have an href attribute, all area elements # that have an href attribute, and all link elements that have an # href attribute, must match one of :link and :visited. A number of user agents have recently implemented changes to handling of :link and :visited that can't be described strictly in terms of an element matching a selector. These are described in more detail in http://dbaron.org/mozilla/visited-privacy . css3-selectors has an exception that allows this: # UAs may therefore treat all links as unvisited links, or # implement other measures to preserve the user's privacy while # rendering visited and unvisited links differently. --http://www.w3.org/TR/css3-selectors/#the-link-pseudo-classes-link-and-visited HTML5 should have a similar exception that allows user agents to be more flexible than requiring that all of the elements listed match exactly one of :link and :visited. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Should :default apply to checkboxes, radios, and options?
On Friday 2010-04-30 13:05 -0700, Tab Atkins Jr. wrote: On Fri, Apr 30, 2010 at 12:12 PM, L. David Baron dba...@dbaron.org wrote: For a long time, Gecko has implemented the behavior that the :default pseudo-class matches checkboxes, radios, and options that are selected by default (i.e., anything that matches :checked by default). I think supporting it for option elements is explicitly stated in the spec where :default was introduced: # One example is the default submit button among a set of buttons. # Another example is the default option from a popup menu. # Multiple elements in a select-many group could have multiple # :default elements, like a selection of pizza toppings for # example. -- http://www.w3.org/TR/css3-ui/#pseudo-default and I think supporting it for radios and checkboxes logically follows from that. However, the HTML5 spec says that :default should not apply in these cases: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-default I don't feel particularly strongly about this one, but it seems like the original intent of :default was to match both things that are the default button and things that are selected by default. Was this difference with existing implementation behavior intentional? By selected by default, do you mean things that had @checked or @selected on page load? Not quite... just things that have @checked or @selected in the markup. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Should :default apply to checkboxes, radios, and options?
On Friday 2010-04-30 13:43 -0700, L. David Baron wrote: On Friday 2010-04-30 13:05 -0700, Tab Atkins Jr. wrote: On Fri, Apr 30, 2010 at 12:12 PM, L. David Baron dba...@dbaron.org wrote: For a long time, Gecko has implemented the behavior that the :default pseudo-class matches checkboxes, radios, and options that are selected by default (i.e., anything that matches :checked by default). I think supporting it for option elements is explicitly stated in the spec where :default was introduced: # One example is the default submit button among a set of buttons. # Another example is the default option from a popup menu. # Multiple elements in a select-many group could have multiple # :default elements, like a selection of pizza toppings for # example. -- http://www.w3.org/TR/css3-ui/#pseudo-default and I think supporting it for radios and checkboxes logically follows from that. However, the HTML5 spec says that :default should not apply in these cases: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-default I don't feel particularly strongly about this one, but it seems like the original intent of :default was to match both things that are the default button and things that are selected by default. Was this difference with existing implementation behavior intentional? By selected by default, do you mean things that had @checked or @selected on page load? Not quite... just things that have @checked or @selected in the markup. Er, markup wasn't the right word. Just things that have @checked or @selected. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Should :default apply to checkboxes, radios, and options?
On Friday 2010-04-30 13:46 -0700, Jonas Sicking wrote: Out of curiosity, what is the use case for :default? For buttons, it's common to present the button that's the default action for a dialog (the one that submits if you hit enter in a textfield, for example), with a thicker border. (For example, in dialog boxes in Windows.) For radios/checkboxes, one might want to present the labels corresponding to the current state in a different font (perhaps bold?) or color so that if a user switches away from the defaults they can switch back without having to remember what they changed. (I believe I've seen UI that does this, although I can't think where.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] Should default styles for h1-h6 match the outlining algorithm?
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#headings-and-sections defines an outlining algorithm that gives each heading an outline depth that doesn't necessarily match its h1-h6 number (at least as I understand it, although I admit I haven't read the details). There's been a bit of discussion at various times on www-style and in other places about adding selectors that would allow CSS to match on HTML's outline depth. However, I was somewhat surprised to see that the rendering section http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#fonts-and-colors suggests default styles for h1-h6 that don't reflect the outline depth at all. Should it? Is the design of the outline algorithm in HTML5 intended to result in better default styles for headings? Or is it expected that the default styles are generally wrong but that CSS provides selectors that let authors easily improve them? (Why?) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Thursday 2010-04-01 23:10 -0700, wha...@whatwg.org wrote: [giow] (0) The CSS rules need to do attribute value matching consistently across HTML and XHTML, despite the rules for interpreting author style sheets. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9335 + p id=case-sensitive-selector-exceptionFor the purpose of the + rules marked case-sensitive, user agents are expected to use + case-sensitive matching of attribute values rather than + case-insensitive matching, regardless of whether a case-insensitive + matching is normally required for the given attribute./p + + p id=case-insensitive-selector-exceptionSimilarly, for the + purpose of the rules marked case-insensitive, user agents are + expected to use spanASCII case-insensitive/span matching of + attribute values rather than case-sensitive matching, even for + attributes in XHTML documents./p + + p class=noteThese markings only affect the handling of attribute + emvalues/em, not attribute names or element names./p Making attribute values case-insensitive in XHTML seems incompatible with longstanding Gecko behavior (though our handling of input's type attribute is buggy, at least) and with the clear intent of XHTML1, and doesn't seem implementable on top of a conformant CSS selectors implementation. Do we really want to do this? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] borders on images inside links
I believe the rendering section should describe a default style
rule, present in Gecko and in Internet Explorer (and also in
Netscape 4.x and earlier, Mosaic, etc.), that gives borders to
images inside links. In Gecko, this is represented as:
:link img, :visited img, img[usemap], object[usemap] { border: 2px solid; }
People have expressed concern that this rule is a bad default
because it's a rule that authors frequently override. I agree that
it's a bad default for HTML that is used as an application, but I
think it's a good default for HTML as a document. And I think there
is content written on the assumption that borders would visually
indicate links -- I know I've written some.
I think we're better off not breaking compatibility here, as it's a
very-long-standing (for the Web) precedent. I'd rather see
15-year-old Web pages continue to work as intended rather than
gradually turn them into something that requires 15-year-old
software to read.
For more information (and the reason that prompted me to post here),
see https://bugzilla.mozilla.org/show_bug.cgi?id=452915 .
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Customize HTML5 forms placeholder style
On Thursday 2010-02-18 13:58 -0600, Tab Atkins Jr. wrote: I agree that having a pseudoelement for the placeholder text is a good idea. Perhaps you could bring it up on the www-style list so we can decide precisely what properties should apply to it? It seems reasonable to apply the same restrictions that we currently put on ::first-line (http://www.w3.org/TR/CSS2/selector.html#first-line-pseudo, last paragraph of the section). It doesn't need to be nearly as restricted as :first-line, since it's tree-like. It's much more like :before and :after. (For more on the distinctions, see the comment I wrote at http://hg.mozilla.org/mozilla-central/file/4cabe72ad940/layout/style/nsCSSPseudoElements.h#l50 , and note that it mentions a third intermediate category, in which some proposed XForms pseudo-elements, and perhaps some future pseudo-elements, would fit.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Customize HTML5 forms placeholder style
On Thursday 2010-02-18 16:21 -0600, Tab Atkins Jr. wrote: Ah, got it. That doesn't seem like a horrible problem to me. Most people don't set color on inputs, and when they do, it's at least guaranteed that the color is *usable* for placeholder, even if it's not ideal. They can just set color on the placeholder directly if they care, though. (My windows theme is green-on-black, so I am very aware when people *do* style their inputs. Setting color:black without a background-color:white is distressingly common, but overall most inputs are unstyled in my experience.) I don't personally feel this is important enough of an issue to justify specificity trickery. I think the question is whether, given author style for the input's text but no specific style for the placeholder, you're better off falling back to the default style for the placeholder or to the author style for the input. It's not obvious to me which is the right answer. Falling back to the author style for the input (what you'd get with a pseudo-class) has the advantage of being more likely to produce legible text (assuming the author styled the input properly). This case may matter for cases where the markup and style are coming from different sources. Falling back to the default color for the placeholder text (what you'd get with a pseudo-element) has the advantage that the placeholder text is more likely to be distinguishable from non-placeholder text. However, there's no guarantee of that, nor is there any guarantee that it's legible or visible at all. (However, having no placeholder text show up at all is already the old-browsers failure mode of the placeholder attribute, right?) I'd be inclined towards the pseudo-class, though, partly since that failure mode bothers me less, and partly since it's a lot simpler (maybe not to implement in one engine, but probably to implement interoperably and to specify, since you need to be careful about what applies and doesn't apply to the pseudo-element). -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Customize HTML5 forms placeholder style
On Thursday 2010-02-18 17:40 -0500, L. David Baron wrote: I'd be inclined towards the pseudo-class, though, partly since that failure mode bothers me less, and partly since it's a lot simpler (maybe not to implement in one engine, but probably to implement interoperably and to specify, since you need to be careful about what applies and doesn't apply to the pseudo-element). And the other advantage of a pseudo-class is that it lets the author style the input in other ways, which might be desirable. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Customize HTML5 forms placeholder style
On Thursday 2010-02-18 16:45 -0600, Tab Atkins Jr. wrote:
Anne suggested in IRC using the pseudoclass approach, and pairing it
with the ::value pseudoelem from the Basic UI Module. You could get
But the key question (from the Webkit bug) is really whether the UA
styles apply to the input itself or a pseudo-element inside of it.
If the UA style is
input:has-placeholder { color: ... }
then, as far as I can tell, there's no point to styling the ::value.
If the UA style is
input:has-placeholder::value { color: ... }
then you get the same cascading result as with an input::placeholder
pseudo-element (styles that don't select the pseudo-element don't
change the UA default), but with the addition that authors can style
the input in other ways.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] [html5] r4483 - [giow] (0) Clarify that br doesn't stop bidi processing. Fixing http://www.w3. [...]
On Tuesday 2010-01-05 03:16 -0800, wha...@whatwg.org wrote: (describing http://html5.org/tools/web-apps-tracker?from=4482to=4483) [giow] (0) Clarify that br doesn't stop bidi processing. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=8363 It might be worth saying that it is equivalent to LINE SEPARATOR in terms of bidi processing, as HTML4 did: # With respect to bidirectional formatting, the BR element should # behave the same way the [ISO10646] LINE SEPARATOR character # behaves in the bidirectional algorithm. -- http://www.w3.org/TR/html4/struct/text.html#h-9.3.2.1 As I understand it, the bidi algorithm [1] has two parts: * resolution, in which characters are assigned embedding levels * reordering, in which the characters are reorderded into their left-to-right display order by, for each N decreasing from 63 to 1, reversing all contiguous runs of embedding level N or higher The importance of being a line separator is that *resolution* is run on paragraphs (so is run on units containing line separators in the middle), but reordering is run on lines (so it is not run on units containing line separators). This means that characters on one side of a line separator can influence the directionality of characters on the other side, but reordering can't move them to the opposite side of the BR (i.e., across lines). For example the markup (where uppercase characters are right-to-left) within a left-to-right direction block: HEB-brREW looks like: -BEH WER whereas the markup: HEB-pREW looks like: BEH- WER (the hyphen appears at the opposite end). -David [1] http://unicode.org/reports/tr9/ -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Uploading directories of files
On Friday 2009-12-11 02:17 -0800, Jeremy Orlow wrote: But regardless.I don't think you could argue that having _some_ path information is worse than _none_, right? Many of those who commented in https://bugzilla.mozilla.org/show_bug.cgi?id=143220 and its duplicates would disagree. Users may not expect the act of uploading a file to give the Web site details of their file system structure. There also seems to be some concern that those details may provide information useful to an attacker. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Charset sniffing from XML prolog
On Wednesday 2009-10-07 23:51 +, Kartikaya Gupta wrote: On Wed, 07 Oct 2009 19:34:18 -0400, Boris Zbarsky bzbar...@mit.edu wrote: On 10/7/09 7:12 PM, Kartikaya Gupta wrote: If a document is served as text/html, but contains an XML prolog with an encoding attribute, it seems that all Firefox, Opera, and Chrome all pick up the encoding from the prolog and use it when parsing the rest of the document. (IE6 does not). The HTML5 spec doesn't seem to include XML-prolog checking in its encoding sniffing algorithm, should it? ?xml version=1.0 encoding=utf-8? htmlinsert utf-8 content here, or alert(document.inputEncoding) for browsers that support it/html data:text/html,?xml version=1.0 encoding=utf-8?htmlscriptalert(document.inputEncoding)/script/html Shows ISO-8859-1 for me in Firefox over here. Strange. I got UTF-8 when I pasted that into the address bar. For reference, the version of FF I'm using is: Maybe you've configured UTF-8 as the fallback encoding? It's a preference (and its default value varies between localizations). Tools - Options - Content - Fonts Colors - Character Encoding - Default Character Encoding. (For other platforms, change Tools - Options to Edit - Preferences (GNOME-based platforms) or Firefox - Preferences (Mac).) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] A New Way Forward for HTML5
On Thursday 2009-07-23 09:48 -0400, Manu Sporny wrote: http://html5.digitalbazaar.com/a-new-way-forward/ I have a few thoughts on this document. The above document says: # The single greatest complaint heard from the standards community # concerning the development of HTML5 is that it has not allowed # for the scientific process. I strongly disagree with this statement. A key part of a scientific process is that the starting point is evidence. I think the development process of HTML5 gives arguments based on evidence more weight than any other W3C work I've been involved in, and has put more effort into gathering relevant evidence than any other W3C work I've been involved in. This is a good thing. Regarding the section Action: Splitting HTML5 into Logically Targeted Documents, I agree that there is value in splitting the specification. However, I see significant danger in the way you propose to split it: separating the specification of what is available to authors and what should be implemented means the specification risks promising to authors what cannot be implemented, or cannot be implemented at a cost proportionate to the benefit (as HTML4 did in a number of places). I'm a little bit puzzled by the inclusion of the section Problem: Partial Distributed Extensibility: it seems to be a technical issue (although a far-reaching one) in a document otherwise about process issues. I'm not sure it belongs in this discussion. Finally, regarding the section Problem: Disregarding Input from the Accessibility Community. I think some of the input that has been ignored or has been felt to be ignored is input that is difficult to act on. Specification development ought to work from requirements to solutions rather than straight to solutions. This is done to make sure that the requirements are addressed, to make sure that the specification does not become more complicated than needed to address the requirements, and (most importantly in this case) to avoid unresolvable debates between parties that are emotionally attached to particular technical solutions. I think a number of the arguments that have been ignored (e.g., some of the arguments over @headers or @summary) have been arguments made *in the face of* evidence that the particular technical solutions do not work in practice, and without presenting the requirements that are not addressed by the HTML5 specification's replacements for those particular (non-functioning) solutions. I think such arguments ought to be ignored, ignoring them is not a problem, and giving those who make them and then complain that they are ignored the power to edit the specification would be a mistake. However, I think HTML5 specification reflects significant consideration for the needs of disabled users, and I strongly encourage more input regarding use cases for and requirements of disabled users that the specification fails to meet. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] UTF-16 encoding default
On Wednesday 2009-07-15 04:24 +, Ian Hickson wrote: Firefox checks to see if the first two bytes are null/not-null or not-null/null and acts accordingly; if they're both not null it uses BE and if they're both null it does something I don't recognise (and checks both the UTF-8 and UTF-16 character encodings in the menu...). That's odd. For what it's worth, the code (the last function in a file incorrectly named nsUCS2BEToUnicode.cpp) looks like it should use BE in any case where there was no BOM and we didn't hit the case where exactly one of the two first bytes was non-null. (You didn't have any autodetection enabled, did you?) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
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] Name for WHATWG Members
On Saturday 2009-01-17 14:46 +0100, James Graham wrote: There seems to be some confusion about whether members of WHATWG are just people on the mailing list or are people on the oversight committee. Since it is almost never necessary to discuss the oversight committee I suggest it is worth using the common term members to mean people on the mailing list and the longer term oversight committee members to mean people in the oversight committee. This would eliminate the confusion and draw attention to the fact that it is the people on the mailing list who are responsible for the technical content of the spec (like W3C Working group members) and that the oversight committee who are responsible only for things like the charter (like W3C staff). I agree that the current use of members is confusing. However, I don't like changing a term immediately from one thing to another. Then any use of that term needs to be qualified with a date. I also think that the term contributors makes it clearer that there aren't any membership requirements in order to participate. So I'd prefer to avoid the term members entirely by changing the references to members to be steering committee, oversight committee, or similar. This might lead to the section of the charter currently entitled Membership saying something like: # Participation and Oversight # # Anyone can contribute by subscribing to the mailing list. The list # of subscribers to the mailing list are termed the contributors. # # Membership in the oversight committee is by invitation only, and # consists of a number of representatives from various browser # manufacturers. This group will provide overall guidance as # described in the charter above. The members of the oversight # committee are currently: # # [...] -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Saturday 2009-01-17 22:25 +0200, Henri Sivonen wrote: The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Actually, the implementation was well underway *before* RDF was a W3C REC, done by a team led by one of the designers of RDF. In other words, it was in Gecko because there were RDF advocates at Netscape (although advocating, I think, a somewhat different RDF than the current RDF recommendations). Compare the dates on: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ http://www.w3.org/TR/1999/PR-rdf-schema-19990303/ http://bonsai.mozilla.org/cvsquery.cgi?treeid=defaultmodule=allbranch=HEADbranchtype=matchdir=mozilla%2Frdffile=filetype=matchwho=whotype=matchsortby=Datehours=2date=explicitmindate=1998-01-01maxdate=1999-01-01cvsroot=%2Fcvsroot -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] attribute media on script element
On Friday 2008-11-14 11:37 +0100, Filippo Levizzani wrote: Would it be possible to have media attribute in the SCRIPT element? Addmitted vaues would be the same of STYLE element (all, screen, print, handheld ...) I'm not quite sure how this would work, since there are two things that seem incompatible: * scripts are executed during parsing / content model construction * whether a media attribute is true can change over time This seems to imply that we'd have to go un-execute a script, or that we'd have to execute later something that was skipped earlier, even when that no longer makes sense. What was the actual use case you were trying to solve with this attribute? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] attribute media on script element
On Friday 2008-11-14 18:53 +0100, Filippo Levizzani wrote: * whether a media attribute is true can change over time but the same applies to style element , I guess Yes, but styles can be applied and unapplied easily. This seems to imply that we'd have to go un-execute a script, or that we'd have to execute later something that was skipped earlier, even when that no longer makes sense. What was the actual use case you were trying to solve with this attribute? For instance, I'd like to call SWFObject function (to replace html content with flash) only if media=screen. Other times there are js funcions that have no sense if a given style sheet has not been applied to the page. Would an API that you call from script that allows you to determine if a given media query matches the default view be sufficient for your needs? That seems like it could be more useful than an attribute that simply prevents scripts from executing, and it avoids introducing similar-looking attributes that actually behave very differently. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] overflow of seamless iframes
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded0.html#seamless doesn't seem to say what happens to overflowing content in seamless iframes. Overflowing content seems likely to occur with the default values of 'width' and 'height', in at least the case where content inside the iframe that is wider than the iframe's containing block things like floats inside the iframe I would suggest that the 'overflow' CSS property apply to the handling of overflowing content inside seamless iframes. This seems like it would make them most like blocks. In any case, it seems like this ought to be defined (although if it were defined by making a more general statement of equivalence that might be good, since I suspect a bunch of other similar things are undefined as well). -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] Use of 'direction' of canvas element
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text has the following bullet point: # Form a hypothetical infinitely wide CSS line box containing a # single inline box containing the text text, with all the # properties at their initial values except the 'font' property of # the inline element set to font and the 'direction' property of # the inline element set to the 'direction' property of the canvas # element. [CSS] This should describe what to do if the canvas element is not in a document (and therefore has no 'direction'). It should probably fall back to 'ltr' as a last resort. However, as an intermediate step, it might be worth falling back to the direction property of the root element (if present) of the canvas element's ownerDocument. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] are relative values of CanvasRenderingContext2D.font live to style changes?
I'm looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text which currently says: # When the 'font-size' component is set to lengths using # percentages, 'em' or 'ex' units, or the 'larger' or 'smaller' # keywords, these must be interpreted relative to the computed # value of the 'font-size' property of the corresponding canvas # element. When the 'font-weight' component is set to the relative # values 'bolder' and 'lighter', these must be interpreted # relative to the computed value of the 'font-weight' property of # the corresponding canvas element. If the computed values are # undefined for a particular case (e.g. because the canvas element # is not in a document), then the relative keywords must be # interpreted relative to the normal-weight 10px sans-serif # default. Suppose that the computed style of the corresponding canvas element changes between when the font DOM attribute is set and text is drawn. Based on the text above, it's not clear to me whether values like '1em' or 'lighter' should be relative to the canvas's values at the time the font is set or the time the text is drawn. In other words: var canvas = document.getElementById(mycanvaselement); var ctx = canvas.getContext(2d); canvas.style.fontSize = 16px; ctx.font = 0.75em sans-serif; // 12px, for now at least canvas.style.fontSize = 32px; ctx.fillText(hello world, 0, 0); // 12px text or 24px text? The text above: # The font DOM attribute, on setting, must be parsed the same way # as the 'font' property of CSS (but without supporting # property-independent stylesheet syntax like 'inherit'), and the # resulting font must be assigned to the context, with the # 'line-height' component forced to 'normal'. [CSS] could *perhaps* be interpreted to mean that it doesn't dynamically update, but it's not clear. I'd prefer if it were static, because for Mozilla, we'd either have to add new infrastructure to handle dynamic style changes for elements inside something that's display:none or we'd have to recompute the style for every text operation (probably the latter). -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] scrollIntoView jarring?
On Wednesday 2008-04-30 13:58 -0400, David Bolter wrote: 1. scrollIntoView not do anything in the case that the element is already fully visible (possibly in the middle of the viewport), or 2. ensureElementIsVisible to be added as described by Daniel Glazman (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html) It seems like authors might actually want different options here for different uses. Aligning things with an edge of the viewport, or with the edge of some other scrollable container, might be useful in some cases, and just ensuring that it is visible might be useful in others. Mozilla has an internal function used to implement a number of different scrolling APIs (including scrolling to named anchors) that has a bunch of options: * scroll into view (no matter where) * scroll to align with a particular edge of the page * scroll only if it's not visible at all I think in many cases these scrolling APIs are about making things that authors can already do (using scrollTop, offsetTop, offsetHeight, offsetParent, and similar properties) easier to do. So I think the main questions to consider for these APIs are: * what capabilities do they provide that can't already be done? * what are the common uses of the existing features for scrolling things into view (perhaps adjusted by how hard it is to do the different possibilities)? (It's also worth thinking about how all of these deal with nested scrollable containers, and about how they deal with the interaction of vertical and horizontal scrolling. The existing text in http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrolling doesn't seem to account for either. But browsers actually do need to handle these, and the spec should describe how.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Issues concerning the base element and xml:base
On Saturday 2008-03-01 17:12 -0800, Maciej Stachowiak wrote: I'd propose that resolution is always done against the base in effect at the time the URI is resolved. So changing the base would never trigger a reload short of another action. That means you'd need to define when every URI is resolved and how long that result is cached. That seems like a substantial amount of specification and testing work. It might interfere with lazy evaluation as a performance optimization, although I suspect that's not an issue for the main case since we already have to resolve all anchors in order to do visited-link coloring. It also breaks some invariants that are nice to maintain, like that removing and reinserting content from a document should produce the same result. (I think this one may actually be important in practice since authors sometimes use removal/reinsertion to work around bugs handling dynamic changes. Although we probably already break it in a bunch of ways as well.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Issues concerning the base element and xml:base
On Saturday 2008-03-01 17:08 -0800, Maciej Stachowiak wrote: How about requiring that the base used is the one in effect when a given relative URI is resolved, and define that URIs for resource-loading elements are resolved at the time the relevant attribute is set or parsed (but for hyperlinks, at the time it is dereferenced). That is easy to That would make whether :link or :visited matches not correspond to what you get when you click on the link, which seems pretty bad. Hyperlinks already need to be resolved eagerly to style links properly. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Colour correction (was: Canvas ImageData comments)
On Sunday 2008-01-20 09:58 -0800, Darin Adler wrote: The proposal from color experts here at Apple is to interpret untagged colors in the sRGB color space. This is what's done with most other untagged color in Mac OS X. For what it's worth, this is exactly what CSS requires for colors specifies for colors specified in CSS: # All RGB colors are specified in the sRGB color space (see # [SRGB]). -- http://www.w3.org/TR/CSS21/syndata.html#color-units (And that's not new; the sentence goes back all the way to http://www.w3.org/TR/WD-css1-960726.html#color-units .) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] must only ambiguity
On Monday 2007-12-24 19:07 +0100, Krzysztof Żelechowski wrote: My rewording for competition: Authors may use elements in the HTML namespace in the contexts where they are explicitly allowed and nowhere else. My rewording for competition: Authors may put elements inside an element only if that element... (because only if is a common and well understood expression.) These won't work because they make the statement a much weaker requirement per RFC 2119: http://www.ietf.org/rfc/rfc2119.txt Changing from a MUST or MUST NOT to a MAY is a substantive change, not a rewording. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Video codec requirements changed
On Tuesday 2007-12-11 02:39 +, Ian Hickson wrote: I've temporarily removed the requirements on video codecs from the HTML5 spec, since the current text isn't helping us come to a useful interoperable conclusion. When a codec is found that is mutually acceptable to all major parties I will update the spec to require that instead and then reply to all the pending feedback on video codecs. http://www.whatwg.org/issues/#graphics-video-codec The text you replaced the requirements with [1] includes the requirement that the codec: # is not an additional submarine patent risk for large companies Is this something that can be measured objectively, or is it a loophole that allows any sufficiently large company to veto the choice of codec for any reason it chooses, potentially including not wanting the video element to succeed in creating an open standard for video on the Web? -David [1] In full, the text is: # It would be helpful for interoperability if all browsers could # support the same codecs. However, there are no known codecs that # satisfy all the current players: we need a codec that is known to # not require per-unit or per-distributor licensing, that is # compatible with the open source development model, that is of # sufficient quality as to be usable, and that is not an additional # submarine patent risk for large companies. This is an ongoing # issue and this section will be updated once more information is # available. from http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#video -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Unicode mappings for lang; and rang;
On Sunday 2007-07-01 21:06 +0200, Øistein E. Andersen wrote: HTML 4.01 maps them to U+2329 LEFT-POINTING ANGLE BRACKET, U+232A RIGHT-POINTING ANGLE BRACKET from `Angle brackets' in the range U+2300--U+23FF Miscellaneous Technical. What's wrong with these mappings, and why shouldn't they also be the mappings in HTML5? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/ pgp6HCOm05g1A.pgp Description: PGP signature
Re: [whatwg] Unicode mappings for lang; and rang;
On Sunday 2007-07-01 23:40 +0200, Øistein E. Andersen wrote: L. David Baron wrote: What's wrong with these mappings, and why shouldn't they also be the mappings in HTML5? The problem is that they are canonically equivalent to CJK characters. Makes sense. I think I misread your original message. (Although changing them at all seems a little scary.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/ pgpBXwTM7quNB.pgp Description: PGP signature
[whatwg] Style sheet objects (was Re: HTML5 is now also hosted by the W3C)
On Thursday 2007-05-10 11:08 +0200, Kristof Zelechovski wrote: Internet Explorer uses style sheet objects instead; the code would be similar to document.styleSheets[0].addRule(.TBW, border-color: red) While it is nonstandard, it would be a good candidate for standardizing It's already standardized (and implemented at least in Mozilla, for many years now); see: http://www.w3.org/TR/DOM-Level-2-Style/stylesheets.html#StyleSheets-StyleSheet-DocumentStyle http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleSheet except that there's no addRule method (there's instead insertRule, although appendRule would be nice), and insertRule takes the rule as a single string, not a separate selector and declaration. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgplDMpa2iv1v.pgp Description: PGP signature
[whatwg] Styling of area elements (as displayed within referencing image)
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.
What Mozilla implements (as of Mozilla 1.8.1 / Firefox 2.0) is
described by the following proposed spec text:
# The CSS 'cursor' property must be applied to areas as displayed
# within the referencing image. Selectors that match the area (such
# as 'area', ':link', ':visited') must apply normally when
# determining what CSS rules match (that is, selectors match the
# area's actual position in the content tree, not the referencing
# image). However, inherited properties must inherit from the
# referencing image rather than from the area's parent element.
Note that this rule causes areas with usable href attributes to be
matched by a rule like :link, :visited { cursor: pointer } in the
UA style sheet, but lets areas without href attributes use the
cursor property from the referencing image.
Also note that I invented the term referencing image for use in
the text above, and it might need to be defined if it's not deemed
sufficiently obvious.
I'm not sure whether the spec should say that other properties don't
apply. Some other properties from [2] may also be useful. But
Mozilla doesn't apply any properties other than 'cursor' to the
display of the area within the referencing image.
(Mozilla also implements this for a elements as used in image maps,
but I think that's been removed from HTML 5.)
Some comments about the behavior of other browsers (with testcase)
are available at [1].
-David
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=302536#c58
[2] http://www.w3.org/TR/css3-ui/
--
L. David BaronURL: http://dbaron.org/
Technical Lead, Layout CSS, Mozilla Corporation
pgp3sd1AQEbJD.pgp
Description: PGP signature
Re: [whatwg] on codecs in a 'video' tag.
On Tuesday 2007-04-03 11:52 -0700, Dave Singer wrote: Surely people have comments or questions on other aspects of our proposal? There is new stuff, new ideas, and open areas, all ripe for discussionwe have engineers standing by, eager to refine and improve the video tag design itself... If you want more comments, it would be good to include a URL to get the proposal (potentially a message in the list archive, if that's the best one). I'm not sure where to find it amid the hundreds of messages on the list. The most prevalent codecs *today* are those in cell phones; heck, Nokia has shipped more digital cameras than anyone else (really). In I don't think shipped implementation count is a useful metric here. What matters is the amount of use. I think the average PC is used for a lot more Web browsing than the average high-end cell phone. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgp02zQXsHMVq.pgp Description: PGP signature
Re: [whatwg] IRIs vs. URIs
On Wednesday 2007-03-14 15:20 +0100, Peter Karlsson wrote: L. David Baron on 2007-03-13: I tend to think it would be good that new uses of URIs/IRIs document that they are really IRIs and therefore this reverse-encoding behavior should not be used, but instead encoding should be done as UTF-8. You cannot have UTF-8 encoding just for the URIs/IRIs, and another encoding for the rest of the source text. To properly parse a URI/IRI in the source document, you must first convert the bytes in the resource into a stream of Unicode characters. No, it's the *encoding* (conversion from characters to bytes) that should be done as UTF-8, not the *decoding* (conversion from bytes to characters). The URIs within the document are decoded along with the rest of the document. But to send them back to the server they need to be encoded (converted from characters back to bytes) and then percent-escaped. If we say they're IRIs then the encoding step is always encoding to UTF-8. But the traditional behavior for URIs has been to encode based on the encoding of the document, which requires tracking, for every URI, what the encoding of the document, style sheet, or script that contained it was. (I don't think Mozilla does this for scripts, but we do for style sheets and documents.) -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgp1U2Bf9RrDe.pgp Description: PGP signature
Re: [whatwg] IRIs vs. URIs
On Wednesday 2007-03-14 20:16 +0100, Bjoern Hoehrmann wrote: Opera, at least for a considerable amount of time, used UTF-8 for the whole reference, I think independently of encodings, domains, and other environment variables. Mozilla was incompatible with that for a long time, always using the document encoding even for the path. I understand this is no longer the case for trunk builds. So the above is a major oversimplification of the issue. (I included the many Western qualifications because the default settings for send-urls-as-utf-8 is regionally different and because I encountered some strange edge cases that result in odd behavior, like sending raw non-ascii octets in the request; details are in Mozilla Bugzilla comment from me, and various list archives). I believe Mozilla's behavior is the way it is in order to be compatible enough with IE's behavior to be usable when browsing East Asian Web sites. We avoid changing our interpretation of Web standards based on localization; that's just too much complexity to test and maintain. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpoLsCBR9wwi.pgp Description: PGP signature
Re: [whatwg] Web Forms 2.0 and the W3C Patent Policy
On Wednesday 2007-03-14 21:59 -0400, Matthew Raymond wrote: The following individuals may or may not have agreed to the W3C Patent Policy regarding the Web Forms 2.0 specification: [...] If your name is on the list above, please agree to the license so we can circumvent the patent policy issue in the HTML WG. Let me know if you've already agreed to the policy so I can take you off the list. Sorry, what patent policy issue? I've seen a lot of comments about patent policy flying around, but I haven't seen any concrete statement of an issue that exists. (And the W3C patent policy is not a license.) -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpIdPblKaQPz.pgp Description: PGP signature
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Sunday 2007-03-11 18:26 +0100, Bjoern Hoehrmann wrote: * L. David Baron wrote: My dismissal of XHTML is that the designers of XHTML and related standards are repeatedly introducing more and more incompatibility between XHTML and HTML, which makes it progressively harder for authors to transition to XHTML (particularly to do so gradually on a large site). Out of curiosity, do you dismiss HTML5 on the same grounds? As an example, http://www.bjoernsworld.de/suchmaschinen/robots-txt.html is as close as it comes to a proper HTML document, but to turn it into a HTML5 document I would need to make many non-trivial changes, e.g. The distinction here is that all of these are either removed features or correctness of document semantics, and therefore don't affect implementation behavior. An implementation that implements both HTML4 and HTML5 will handle all of them, and therefore authors can transition gradually between the two (although they'll technically not be conformant to either while doing so, and many may well stay in that state permanently). (The value of having these things as changes in HTML5 comes from authors who use conformance checkers that will tell them to avoid these bad practices, not from implementations behaving differently.) -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpl5KXWWV5cH.pgp Description: PGP signature
Re: [whatwg] Thesis draft about HTML5 conformance checking
On Saturday 2007-03-10 23:41 +0100, mozer wrote: Liam Quin (with only one n) No, Liam Quin [1] and Liam Quinn [2] are two different Canadian members of the Web standards community, and should not be confused with each other. The latter was responsible for the WDG HTML Validator, so Henri's spelling is correct. -David [1] http://www.w3.org/People/Quin/ [2] http://htmlhelp.com/~liam/ -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpVDa5ExYuRi.pgp Description: PGP signature
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Thursday 2007-03-08 00:09 +0900, Michael(tm) Smith wrote: It's really amusing to see people continuing to trot out matter-of-fact statements dismissing XHTML. Those statements seem to fall into two basic types that can be paraphrased as either: My dismissal doesn't fall into either of those types. My dismissal of XHTML is that the designers of XHTML and related standards are repeatedly introducing more and more incompatibility between XHTML and HTML, which makes it progressively harder for authors to transition to XHTML (particularly to do so gradually on a large site). For example: * The W3C XHTML Working Group insists that all the HTML-specific statements in CSS don't apply to XHTML (and got the CSS working group to put this into the CSS specs). This means that an author converting HTML to XHTML doesn't need to just convert the syntax used in their markup (including case of tags), they may also need to make significant redesigns to their CSS to avoid depending on the HTML-specific rules in CSS. * When namespace APIs were added in DOM Level 2, the W3C DOM Working Group insisted that HTML (which has no concept of namespaces) be reflected into those APIs as though it were a series of elements in no namespace. This is different from the way XHTML is reflected, which means that in many cases it is significantly harder than it should be to write a script that works with both XHTML and HTML (which is necessary for site-wide scripts when one is starting to use XHTML on a site, especially if the use case for switching to XHTML is compound documents, where there might be elements called a that aren't HTML a elements). Fortunately the WHATWG HTML5 spec reverses this bad decision. Almost all of the claimed advantages of XHTML come from its XML-ness, so why keep adding more incompatibility just for purity's sake? My dismissal of XHTML is that if those designing standards that are not yet widely adopted (compared to HTML) keep making it harder and harder to transition, they'll prevent that transition from ever occurring. And if that transition is never going to occur on a large scale, why worry about it? -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpEGHw5cO4FD.pgp Description: PGP signature
[whatwg] image captions and fallback content
On Tuesday 2006-11-28 01:49 +, Ian Hickson wrote: figure img ... legend ... /legend /figure There are special rules for what to do with fallback that basically make the caption disappear (though of course this won't happen in legacy UAs). I'm assuming the rules you're referring to are those at: http://www.whatwg.org/specs/web-apps/current-work/#figure0 Are these rules worth the complexity they add? I think in many cases they may actually be harmful. In particular, authors who aren't thinking much about fallback content may be writing captions that would be the most useful fallback content available. Insisting that those captions not be available when there is no fallback content seems like a bad idea. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpcPUv0B4iEk.pgp Description: PGP signature
Re: [whatwg] [canvas] globalCompositeOperation poorly defined
On Friday 2006-07-21 09:07 -0700, L. David Baron wrote: On Friday 2006-07-21 11:14 +0300, Henri Sivonen wrote: I gather that a normative reference to the Porter–Duff paper is needed: http://keithp.com/~keithp/porterduff/p253-porter.pdf Perhaps, assuming that's what's been implemented, although that would only define 10 of the 12 operators in the spec. But that paper doesn't define binary operators for 'darker' and 'lighter', which seem to be among the less-interoperable right now. (It defines a unary 'darken' operator over a space of numeric parameters.) I've written tests for the 11 operators defined in the paper, plus a test for 'darker' that assumes Quartz's PlusDarker operator [1]: http://dbaron.org/tests/canvas/composite-operations4 It seems like 'darker' is currently not interoperable, and might be unlikely to become interoperable, due to different availability of compositing operators across platforms. (Quartz has PlusDarker. Mozilla uses the saturate operator that is provided by Cairo/libpixman (and also by XRender), which is described in [2] and [3], but seems to me to be quite different.) One solution to that problem would be to remove 'darker' from the spec rather than defining it one way or the other. Thoughts? -David [1] http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSCompositingOperation [2] http://keithp.com/~keithp/render/protocol.html [3] http://lists.freedesktop.org/archives/cairo/2005-June/004224.html -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpIy5zryxgHU.pgp Description: PGP signature
Re: [whatwg] [canvas] globalCompositeOperation poorly defined
On Friday 2006-07-21 11:14 +0300, Henri Sivonen wrote: I gather that a normative reference to the Porter–Duff paper is needed: http://keithp.com/~keithp/porterduff/p253-porter.pdf Perhaps, assuming that's what's been implemented, although that would only define 10 of the 12 operators in the spec. But that paper doesn't define binary operators for 'darker' and 'lighter', which seem to be among the less-interoperable right now. (It defines a unary 'darken' operator over a space of numeric parameters.) -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpuKKzyL2opN.pgp Description: PGP signature
Re: [whatwg] Canvas 2d methods
On Sunday 2006-07-02 22:47 +0200, Stefan Gössner wrote: hmm ... ctx.scale(2,1) .rotate(Math.PI/4) .translate(4,-6); illustrates a sequence of manipulations semantically very well, doesn't it? In my opinion, this pattern generally makes sense semantically when used on immutable objects (e.g., strings in JavaScript). I don't think this pattern makes sense for mutable objects. It just suggests immutability. And making the canvas context objects immutable doesn't really make sense without much more significant changes. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpoKIu74a1g2.pgp Description: PGP signature
Re: [whatwg] Spellchecking proposal #2
On Saturday 2006-06-24 11:45 +0700, Alexey Feldgendler wrote: IMHO we should not rely on unspecified heuristics. In some browsers, they work rather well, in some they might constantly fail. Leave heuristics for invalid pages, quirks mode etc -- or document these heuristics. I agree, but for a different reason. The problem with heuristics is not that they might be better in some browsers and worse in others. The problem is that heuristics are only heuristics when they operate on input written without knowledge of the heuristics. When the input was written with knowledge of the heuristics, they become de facto standards. In other words, authors will figure out what the heuristics are and then write markup to match the heuristics rather than to match the semantics of their content. Authors will learn what triggers spellchecking (or not) in Mozilla, and write whatever markup, however inappropriate, gives the choice of spellchecking that they want. Then other browsers will be forced to copy whatever Mozilla did. So if we're going to end up with a standard anyway, why not admit it and figure out what it should be rather than ending up there accidentally? -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpp9ZvKOeoW7.pgp Description: PGP signature
[whatwg] [canvas] globalCompositeOperation poorly defined
The values of globalCompositeOperation are very poorly defined: http://www.whatwg.org/specs/web-apps/current-work/#globalcompositeoperation Some math is probably needed; prose alone seems unlikely to be sufficient. I made a quick test at: http://dbaron.org/tests/canvas/composite-operations Trunk Mozilla and Opera 9 do not interoperate on at least the following (ignoring differences that could be attributed to rounding): source-atop source-over (the default!) destination-atop lighter darker xor (Safari seems to show the colors as either random noise (latest for 10.3/PPC) or blank (latest for 10.4/Intel).) Looking at Mozilla's code, it implements copy and source-over as the same thing; from the code I'd guess that source-over was the incorrect one, and this test seems to agree. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpg1jtWWVnIh.pgp Description: PGP signature
Re: [whatwg] input type=text accept=
On Friday 2006-06-09 00:42 +, Ian Hickson wrote: On Wed, 31 May 2006, L. David Baron wrote: I don't see why the same attribute _shouldn't_ be used to determine the type of data to allow, and whether to do spell checking or not. After all, whether to spell-check is directly related to what kind of data it is. This sounds a lot like object, which allowed for tons of features but didn't specify them precisely. Are you planning to specify exactly what the semantics of every MIME type are for all of these features? No, because I don't know what those are, and want to allow for browser vendors to increase their feature set without having to have the spec updated each time. It doesn't seem like this is an area that requires interoperability (who cares if one browser auto-indents and another colours and spell-checks, other than the user of each browser?). The original use case, as I understand it, was roughly authors want to disable spell checking on some textareas. Is the reason that they want to disable spellchecking only that the contents are not text/plain? I doubt it. Doing what you propose, especially if it is extended to other features, will just encourage authors to use incorrect MIME types to get particular side-effects in particular user agents. It seems more likely to be that the textarea is expected to contain a particular type of text, such as abbreviations or some form of code. The content is unlikely to have an assigned MIME type. I suppose one could be made up, but that would presumably disable everything a UA did on the basis of the contents, which wouldn't necessarily be appropriate. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpffr0IKPp8K.pgp Description: PGP signature
Re: [whatwg] input type=text accept=
On Friday 2006-06-09 01:17 +, Ian Hickson wrote: Given that requiring a new flag per feature is not an option (as, as mentioned before, it would require a central authority to add these features, slowing the introduction of new features and discouraging experimentation), what solution would you propose instead? I think it is an option, and I don't see why you're so insistent that it isn't. Authors are actually going to want interoperability; to get that, it's required. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpKXHP02UwFo.pgp Description: PGP signature
Re: [whatwg] input type=text accept=
On Wednesday 2006-05-31 19:51 +, Ian Hickson wrote: The Mozilla guys propose (in bug 339127) to make the accept= attribute on input elements also apply to types other than type=file, with the same meaning as we currently have on textarea. Their particular use case is to use this as a hook for showing or hiding the spell-check UI. What do people think? Good idea? Bad idea? This seems like a bad idea to me. We might want to use the accept attribute in the future to indicate what types of content can be sent, and thus what types of input the user agent should allow. Overloading that to get a boolean for whether spellchecking should be enabled seems broken. I'd rather see a new attribute for this. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpW1qXwiBsEF.pgp Description: PGP signature
Re: [whatwg] input type=text accept=
On Thursday 2006-06-01 00:41 +, Ian Hickson wrote: Well, we want to avoid adding attributes for each feature (spellcheck=on autoindent=on syntaxhighlight=on syntaxcheck=off, as browsers add each feature) -- instead it is better, IMHO at least, to let the UA determine how it should behave based on some semantic information, such as, in this case, the type that is expected to be entered. I don't see why the same attribute _shouldn't_ be used to determine the type of data to allow, and whether to do spell checking or not. After all, whether to spell-check is directly related to what kind of data it is. This sounds a lot like object, which allowed for tons of features but didn't specify them precisely. Are you planning to specify exactly what the semantics of every MIME type are for all of these features? And any others people might want? And are there really MIME types that accurately represent the semantics of all the combinations of even just the 4 features you list above that authors will want? If every combination needs a name, what if people want to toggle six different things? Generic parameters to MIME types might be a nice solution, but I think we're past that point, unless you want to invent a syntax that represents MIME type - parameter list pairs. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgp2AY0tJ6CDb.pgp Description: PGP signature
Re: [whatwg] [html5] html:style parsing
On Saturday 2006-03-11 00:22 +, Ian Hickson wrote:
On Fri, 4 Nov 2005, L. David Baron wrote:
On Monday 2005-10-31 10:53 +1100, Lachlan Hunt wrote:
The current web-apps draft:
| For styling languages that consist of pure text, user agents must use
| a concatenation of the contents of all the text nodes and CDATA nodes
| that are direct children of the style element (ignoring any other
| nodes such as comments or elements), in tree order.
The specification should be clearer that for SGML-based documents (as
opposed to XML-based documents), the parsing rules may mean that things
that look like child nodes aren't actually child nodes (since STYLE has
CDATA parsing according to the HTML4 DTD, and is generally implemented
far closer to that than to normal parsing). If you specify anything
precisely regarding this, please write testcases to make sure it matches
what's actually implemented, which is probably what's required by the
Web.
Could you expand on this? I don't really follow.
STYLE and SCRIPT elements have similar parsing rules in tag-soup HTML,
where everything is treated as text until /style or /script. This
is why you see an alert with stuff that looks like tags in:
data:text/html,stylebi/stylescriptalert(document.getElementsByTagName('style')[0].firstChild.data)/script
or that script like:
script
document.write(bfoo/b);
/script
actually works.
SGML says something slightly different (IIRC, that the element ends at
the first /, and if the thing that follows isn't the tag name then
the document is wrong), but it is based on an underlying SGML concept (a
content model of CDATA in the HTML4 DTD for both elements (different
as an element content model than as an attribute value type), rather
than #PCDATA).
If the spec is already clear on this, then perhaps nothing needs
changing; I was just responding to the quoted text.
-David
--
L. David BaronURL: http://dbaron.org/
Technical Lead, Layout CSS, Mozilla Corporation
pgpfpZEf4sBZg.pgp
Description: PGP signature
Re: [whatwg] WA1: Conformance requirements
On Thursday 2006-03-09 17:56 +, Ian Hickson wrote: On Thu, 9 Mar 2006, L. David Baron wrote: It says: Conformance requirements phrased as requirements on elements, attributes, methods or objects are conformance requirements on user agents. The ins and del elements must implement the HTMLModElement interface: But it's their DOM objects that must implement the HTMLModElement interface, not the elements themselves. I can't find any examples on attributes, but I could imagine having some. I agree that often there are requirements on elements and attributes that are really requirements on authors. I'll have to go through and fix that. Perhaps the way to fix it is to say: # Conformance requirements phrased as requirements on elements or markup # attributes are conformance requirements on documents. # # Conformance requirements phrased as requirements on DOM attributes, # methods, or objects are conformance requirements on user agents. It seems like that would catch more of the common cases. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgplBGobr8POO.pgp Description: PGP signature
[whatwg] WA1: Conformance requirements
Some comments on section 1.8, Conformance requirements in the 2006-02-16 draft of Web Applications 1.0 (whose permanent URL claims to be http://www.whatwg.org/specs/web-apps/current-work/ ). The opening sentence: As well as sections marked as non-normative, all diagrams, examples, and notes in this specification are non-normative. is unnecessarily complicated. Instead, I would suggest combining it and the following sentence: All of this specification is normative, except for sections marked as non-normative, diagrams, examples, and notes. It says: This specification describes the conformance criteria for user agents (implementations and their implementors) and ... But I don't think a person who implements a conformant implementation of the specification is himself conformant to the specification. I'd take out and their implementors. (Likewise for authors of documents.) I'm also not entirely sure that user agent is an appropriate term for all of the implementations described here. I think it refers to an implementation that a user uses to access the Web, i.e., a browser. But the use of that term may be too ingrained in the spec to remove it. It says: Conformance requirements phrased as requirements on elements, attributes, methods or objects are conformance requirements on user agents. They are? It seems like they're much more likely to be conformance requirements on documents. I'm having trouble finding a single example that I think is a requirement for a user agent. The User agents with no scripting support should probably either (1) not be a toplevel item within the dl or (2) import the requirements of one of the previous items in the definition list, as the item before it does. Otherwise there appear to be no conformance requirements for such user agents. (I tend to think that perhaps both the non-interactive and no-scripting rules should be exceptions within the Web browsers section, though.) The requirement that authoring tools must generate conforming documents should probably also make the distinction between the three types of conformance requirements made in the section on conformance tools. I would say that authoring tools must generate documents that conform to the first two requirements and should encourage their users to generate documents that conform to the third. I'd also allow an exception for preservation of nonconformant content across editing operations, since in editors often should not change content unrelated to what is being edited. One comment on the following section (1.9 Terminology) while I'm here: use of svg:rect as an example should probably be change to an example that's actually defined by the table following it. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpuyTtYjFYjx.pgp Description: PGP signature
[whatwg] Status of Web Applications 1.0?
I'd like to see a little more information in the Status of this Document section of Web Applications 1.0. In particular: * Are there large sections likely to appear in the document in the future? If so, what? Section 1.10 (Miscellaneous) suggests that there are. (Although I'm not sure requiring mutation events is a good idea, so I might want to see one fewer.) * What other specifications is this document intended to replace (i.e., describe all the relevant features from) and what other specifications is it intended to refer to? In particular, if I find features in HTML 4.01 that are widely implemented and are not described in this document, should I be sending individual email messages to this list pointing out the omissions? -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgplnQKPMkzff.pgp Description: PGP signature
[whatwg] WA1: Lists
The following are comments on section 2.8 (Lists) of the 2006-02-16 draft of Web Applications 1.0 [1]. The text on list numbering seems to lack conformance criteria. The term ordinal value of a list item should probably more clearly be a definition (and not split into multiple places), and there should perhaps be some user-agent conformance criteria regarding the ordinal value of a list item. However, such requirements should be careful not to require a specific display when stylesheets change the display from the default. Also, section 2.8.3 seems to suggest that the value attribute on li applies only to the first list item, whereas 2.8.1 says it works on all li elements. This section should perhaps also give error handling requirements for list items that are not a child of a ul, ol, or menu, regarding list numbering semantics. Should this specification describe the type attribute for ul, ol, and li elements that is in HTML4? I believe it's widely implemented. (Mozilla and KHTML implement it, anyway, although the latter only for ol. I'd test Opera, but data URLs don't seem to work in the version I have with me.) -David [1] http://www.whatwg.org/specs/web-apps/current-work/ (which is what the document claims the permanent URL for that version is) -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgp2e5TJYBi90.pgp Description: PGP signature
[whatwg] Better model for avoiding history spam from pushState?
In http://lists.w3.org/Archives/Public/public-webapi/2005Nov/0017 , I wrote a comment on a WHATWG spec, http://whatwg.org/specs/web-apps/current-work/#scs-session , which I quote here: On Monday 2005-11-21 07:44 -0800, Kenny wrote: [...] My big concern with both document.save and pushState is security. The pushState method has a recommendation for security, It is suggested that to avoid letting a page hijack the history navigation facilities of a UA by abusing pushState(), the UA provide the user with a way to jump back to the previous page (rather than just going back to the previous state)., but if this is not implemented, malicious developers could take control of the users navigation. I think a better solution than extra user interface is a solution like what popup blocking uses: pushState (like window.open these days) should only be allowed while handling a user event like a click or a keypress that expresses the user's choice to navigate to a different state (like navigating to a different page). -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpc9FQOIEuLW.pgp Description: PGP signature
Re: [whatwg] [WF2] Readonly and default pseudoclass matching
On Sunday 2005-07-31 11:29 -0500, Boris Zbarsky wrote: Without knowing the details of how :hover came to be, I may be setting myself up on this one, but I'll bet that it wasn't originally defined in something like an HTML spec as only applying to links, then was redefined to apply to all elements after the fact. It was defined in CSS1 to apply to links and then broadened in scope in CSS2. You're thinking of :active. :hover was not in CSS1 at all, and no specification that I know of limited it to links. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, The Mozilla Foundation pgpzwEmjvspTe.pgp Description: PGP signature
Re: [whatwg] WA1: base and href
On Monday 2005-07-18 08:44 -0400, fantasai wrote: In HTML 4, the 'href' attribute of the base element is #REQUIRED. Is there a reason why in HTML 5 it is not required? base target=foo is pretty common on pages that use frames. Then again, the web apps spec doesn't seem to mention target at all. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, The Mozilla Foundation pgpye2wgfMVRX.pgp Description: PGP signature
