[whatwg] localStorage cache expiry
Hi All, Last week I put together a small javascript library titled cache.js, which is basically localStorage—only, with cache expiry. https://github.com/benschwarz/cache.js This somewhat mimics the cache expiry patterns seen elsewhere on the web, especially with key/value stores such as memcached. I know that the question of doing this within the HTML spec has been discussed before— (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-July/027429.html) so I figured it would be worth posting to this list. I realise that my library doesn't expire keys until they're 'called' (read the source), but I'm happy to accept contributions or discuss API features with anyone who decides that cache.js doesn't do what they're interested in… From there—I'd think it to be feasible to share the findings with the whatwg/w3c in an effort to extend the current scope of localStorage/sessionStorage. I'm looking for feedback and discussion that will aid the HTML5 storage specification, with real software as a form of user requirement, rather than imagination. Cheers, Ben Schwarz -- + germanforblack.com + ab-c.com.au
Re: [whatwg] Content-Disposition property for a tags
On 02.08.2010 18:56, Tab Atkins Jr. wrote: 2010/8/2 Kornel Lesińskikor...@geekhood.net: Downloads can be forced already with Content-Disposition: attachment. It's just harder to do, and unfortunately that doesn't stop webmasters from trying. Popular PHP snippets for forcing download are among the most disgusting cargo-cult code I've ever seen — they're collection of self-contradictory and nonsensical HTTP headers, break caching and resuming, and often have security vulnerabilities. It would be great if we could obsolete those scripts. It would be great if those scripts could just get fixed. Indeed; I've used those code samples, and since the entire area is basically voodoo to me, I still have no idea which headers I sent did anything and which are useless or even harmful cruft. In general, even well-educated authors have no clue what they're doing here. I believe the spec for C-D is sufficiently clear. But you still need to read it :-). Best regards, Julian
Re: [whatwg] Content-Disposition property for a tags
On 06.08.2010 05:49, Bjartur Thorlacius wrote: ... IMO there should be a standard metadata wrapper that should be around virtually all files being passed around the Internet. Downloaders should register the metadata to xattrs or somesuch and uploaders should collect said metadata and rewrap it. Technically application/http could be used. ... There is a widely deployed metadata wrapper; it's the HTTP message headers. Best regards, Julian
Re: [whatwg] Proposal for secure key-value data stores
2010-12-01 21:43 EEST: Aryeh Gregor: On Tue, Nov 30, 2010 at 6:15 PM, Ian Hickson i...@hixie.ch wrote: It cannot, and should not. It's a user concern. If as a user I want all data that you send me to be printed unencrypted and dropped out of my office window for anyone to read, then I should be allowed to do that. :-) It's legitimate for an organization to require people to handle data in a certain way if they want web access to it. For instance, a company could reasonably require that if users want to work from home, they have to obey certain security practices to avoid leaking private data -- e.g., information about the company's clients or users that might be protected by privacy laws or company privacy policies. [...] If a company or any other entity deals with data that must not be leaked, they definitely should not allow any random (home or other) workstation to access the data. Either the user using the workstation is able to decide by himself that the workstation is secure enough or the user cannot use the workstation for secure stuff at all. Even, if we had a hypothetical secure workstation that is based on signed binary executed by BIOS (or some other firmware boot method) and only that binary will only execute other signed binaries, the workstation cannot be guaranteed to be safe. If the user cannot inspect that the hardware has not been temped with, there's no way to make sure that the environment is safe. (There could be an extra hardware component that makes the hardware unsafe - for example, a hardware keylogger inserted between keyboard and keyboard connector, extra hardware soldered on the motherboard that interferes with the memory bus to hack the hardware or something more obscure. See Xbox 360 hacking for an example.) In addition to these major issues, there's still the minor(?) issue of bugs in the software. See security vulnerabilities in software for examples. In the end, my point is that there's absolutely nothing an UA could do to verify that the environment is safe. If somebody claims to do anything else, beware, he's trying to sell you some snake oil. -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] Content-Disposition property for a tags
Am 07.12.2010, 10:13 Uhr, schrieb Julian Reschke julian.resc...@gmx.de: It would be great if those scripts could just get fixed. Do you actually think that would HAPPEN? I think not. Better have people get rid of them entirely. Though that wouldn't happen either. I'm still all for such a property in a hrefs. I personally hate writing scripts to do something so simple. I think we could name it declaration of content. Why should HTTP, the protocol underlying the HTML language, have to take care of declaration of content? Shouldn't the HTML file itself have the power over that? We have a lot of that already, like content types, etc. But we can not yet declarate content which is MEANT for downloading to your hard drive. This is a big hole in my opinion. Best regards, Julian My regards too.
Re: [whatwg] Content-Disposition property for a tags
On 07.12.2010 18:51, Dennis Joachimsthaler wrote: Am 07.12.2010, 10:13 Uhr, schrieb Julian Reschke julian.resc...@gmx.de: It would be great if those scripts could just get fixed. Do you actually think that would HAPPEN? I think not. Better have people get rid of them entirely. Though that wouldn't happen either. I'm still all for such a property in a hrefs. I personally hate writing scripts to do something so simple. I think we could name it declaration of content. Why should HTTP, the protocol underlying the HTML language, have to take care of declaration of content? Shouldn't the HTML file itself have the power over that? We have a lot of that already, like content types, etc. But we can not yet declarate content which is MEANT for downloading to your hard drive. This is a big hole in my opinion. ... I'm not against adding this in principle; but it shouldn't keep us from improving the situation for what's already there. Having multiple ways to do the same thing causes real cost; you need to explain when to use what, and define which information takes priority. Also; be sure to replicate what's needed from C-D, namely the filename information. Has it ever been considered to use target=_download (just made up) for this? Best regards, Julian
Re: [whatwg] location.reload() on document.open()ed documents
On Tue, 24 Aug 2010, Boris Zbarsky wrote: On 8/24/10 6:13 PM, Ian Hickson wrote: So basically, translating this to specese: Document objects on which you call open() have an override reload flag set and an initially empty source cache added. When you call document.write() on a document with the override reload flag set, also append the text to the document source cache. When you reload a document that has the override reload flag set, instead of reloading from the network, just stream the data in from the document source cache. Is that right? That seems like an accurate description of the Gecko behavior. After some discussion with some other browser vendors, I've specced this. The other browser vendors didn't seem especially enthusiastic about it, but did not say they wouldn't implement it eventually... There's some weirdness in terms of the document encoding being set to whatever it's set to while the data is actually just read directly as UTF-16, etc, but that seems like an implementation detail; the spec just needs to specify that the data is read as characters, not bytes, and what the document encoding should be set to. The spec is a little hand-wavy about this, but if it's unclear I'll fix it in a subsequent patch. (It uses basically the same hand-wavy terminology as is used for other invocations of the parser from a string.) Also doing this for history navigation is rather scary too, but I guess could be done. History navigation across document.open() is supported in at least IE and Gecko right now. I seem to recall it being rather broken if supported at all in Webkit. I don't know that I've ever tested Opera. Per spec, currently document.open() replaces the current page rather than allow navigation. I'm not sure how to allow navigation since the Document doesn't change but still can't be reused. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r5399 - [giow] (2) Define option.selected; make option disabled selected still get sel [...]
On Tue, 31 Aug 2010, Simon Pieters wrote: Maybe select requiredoption value selected disabledChoose one... should be allowed? I considered that, but since disabled options don't get selected, that wouldn't work without yet more special-casing. The spec allows select requiredoption valueChoose one...option selectedFoo. Maybe it should require the label option to be selected by default (either implicitly or explicitly) when the select has required? No, otherwise there'd be no way to just select the current value without removing the label. The spec currently doesn't require there to be any select label option if the required attribute is present on select. Right, the label doesn't have to be present. Why would we require one? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] location.reload() on document.open()ed documents
On 12/7/10 5:10 PM, Ian Hickson wrote: Per spec, currently document.open() replaces the current page rather than allow navigation. I believe there are cases where that would cause us to break compat. Note that neither IE nor Gecko does a replace load there, last I checked. I'm not sure how to allow navigation since the Document doesn't change but still can't be reused. What Gecko ends up doing is creating a new Document when navigating history to or from a document.open() result. -Boris
Re: [whatwg] time element feedback
On Tue, 31 Aug 2010, Martin Janecke wrote: (1) There's the example of relative date phrases that refer to an absolute date. For example: time datetime='2009'Last year/time's temperature was above average. What's the use case here? What problem is this solving that isn't solved by just writing this?: span title=2009Last year/span's temperature was above average. Before we add features to HTML, we follow the steps described here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F I am not aware of any use cases or problems here (steps 1 and 2). (2) There's the example of dates written in a local format that is not widely understood anywhere else in the world. For example: time datetime='2010'平22年/time saw no major earthquakes in Japan. Besides, time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. Most examples given in the Wiki are use cases for this. Of course not only Japanese would profit but anyone who uses a different calendar from the Gregorian one. This specific use case I agree has merit; as I've said before, though, we should wait to see if the similar features already in the spec gain traction with implementors and authors before adding yet more features here. The danger otherwise is that we overload implementors with too many new features, and they don't support any of them. On Mon, 9 Aug 2010, Tantek Çelik wrote: HTML5 provides mechanisms for both semantically inputting datetime values (via the 6 new datetimeinput types), and semantically outputting datetime values (via the newtime element). However, the types/granularities of dates and times that are supported do not match up on input vs output, and they should. Why? From a design, learning/teaching perspective, it is much better if they are made to match up, that is if every type/granularity of datetime that can be entered can also be semantically marked up (and vice versa). Why? This would be intuitive – at least to me – and I assume to others as well. It's less complicated if there are less differences, it's less to keep in mind. Supporting different date formats for both will most likely lead to more incorrect usage than in case of matching date format support. I think one can argue similarly that things are less complicated when there are fewer features. I'm not sure that either is more compelling than the other. Given that we can complete the pattern once we have implementation experience, though, that seems like the best bet on the short term. It would also be nice to have a year state forinput, as it has more use cases than week, and it would allow combining with the month state for e.g. credit card info. Can you show me a page that has a special control for year input, rather than just a regular text input? Here are results of a quick research: The Bank of Canada (select) http://www.bankofcanada.ca/en/rates/exchform.html (I am aware that this usage would not be replaced by a year only input, still it shows that not all people think text-only suits best for year input.) Japanese year converter (select) http://www.allcalendars.net/JapaneseYearConverter.php Kitco charts (select, input type=checkbox) http://www.kitco.com/charts/historicalgold.html Especially note the YEARLY GOLD CHARTS section. It seems to me that HTML already satisfies their use cases completely here, without needing any new features. This is in contrast to date pickers, where authors have frequently found that HTML does _not_ satisfy their use cases, to the point of them using JS libraries to have custom date pickers. On Tue, 31 Aug 2010, Martin Janecke wrote: I understand that it's not good to implement features that won't be used by anyone in the end. Nevertheless I am worried that this could lead to a chicken or the egg dilemma, i.e. HTML waits for CSS to implement styling (year-only) dates and CSS waits for HTML implementing year-only-dates before making them stylable? HTML isn't waiting for CSS to make the first move -- HTML has already gone a step beyond what CSS supports here. Now we have to make sure we also support this in CSS, before adding even more to HTML. Generally when technologies work together like this they leap-frog each other, roughly in sync with implementations. This ensures that the whole platform doesn't ever get too far ahead of implementations, and it ensure that we don't go too far into the weeds with a bad idea before stopping. The remainder of this thread discussed the pros and cons of having time localise times. This issue will be decided by the market one way or the other; it's not clear to me that we can make progress on it here. -- Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] XMLHttpRequest and HTML5
On Tue, 31 Aug 2010, Anne van Kesteren wrote: On Tue, 31 Aug 2010 01:58:52 +0200, Ian Hickson i...@hixie.ch wrote: On Sat, 7 Aug 2010, Anne van Kesteren wrote: 2) Is there any reason we cannot also use this no browsing context clause to define document.cookie rather than having a special type of Document object? Seems much better. Since the spec is already written... I can see cases where you could have a Document that had no browsing context but did have cookies. So... But there are no such cases currently. It would be nicer if the special casing was the other way around so XMLHttpRequest did not have to say anything. (And Web DOM Core when it is written.) I've changed the spec to do this automatically for browsing-context-free documents, so you can remove the text from XHR. (I still internally to the spec use the term, since data: documents still fall into that category.) 6) If you provide some hook or tell me how to do it I can define the origin of the Document returned by responseXML in XMLHttpRequest. HTML already defines this. Or do you mean we should move that to the XHR spec? That is what I meant, yes. Done. See the diff for sample text (in a comment). If we can do all this that should turn it into a one-way dependency with most definitions being completely self-contained. I'm not sure it's worth it in the case of the origin thing. So what happens when we define how to get a Document out of a File? We would update the HTML spec. Or, now, the File spec can define it. Either is fine by me. I still think that we should set up a post-processing step that merges all these specs into one anyway. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] reset algorithm doesn't seem to reset input type='file'
On Fri, 3 Sep 2010, Mounir Lamouri wrote: It looks like the reset algorithm for input elements is considering all types except the input type='file'. Shouldn't empty the list of selected files be added? It looks like this has been fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Descendents of source and track elements should be skipped when serializing HTML fragment (10.3)
On Tue, 7 Sep 2010, Ryosuke Niwa wrote: In HTML fragment serialization algorithm, we skip elements with empty content model in step 2.2: [...] For consistency, I propose to skip children of source and track elements as well. Oops. Added. Thanks. Also, the algorithm does not seem to specify the behavior on deprecated (or undocumented) elements such as isindex. Can we assume that the serialization of such elements are UA-defined? No, such elements must be treated as unknown elements when serialising. image and isinde are the only two I'm aware of, but they get processed specially in the parser, and aren't considered real elements. (They are documented, though.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On Wed, 8 Sep 2010, Boris Zbarsky wrote:
Consider this testcase:
!doctype html
html
body
canvas id=c width=200 height=200/canvas
script
try {
var c = document.getElementById(c),
t = c.getContext(2d);
t.moveTo(100, 100);
t.lineTo(NaN, NaN);
t.lineTo(50, 25);
t.stroke();
} catch (e) {alert(e); }
/script
/body
/html
Behavior in the spec seems to be undefined (in particular, no mention is
made as to what the canvas API functions are supposed to do if
non-finite values are passed in). [...]
On Tue, 7 Sep 2010, Sam Weinig wrote:
In 4.8.11.1 the spec does state:
Except where otherwise specified, for the 2D context interface, any
method call with a numeric argument whose value is infinite or a NaN
value must be ignored.
Right. This was intentional; if I recall correctly it was based on the
idea that 3D code rendering to a 2D canvas would often find itself
dealing with asymptotic behaviour and that it was better to silently
ignore such edge cases than to bail entirely as used to happen.
There's actually a comment to that effect in the spec source:
pExcept where otherwise specified, for the 2D context interface,
any method call with a numeric argument whose value is infinite or a
NaN value must be ignored./p
!--
Philip Taylor wrote:
My experience with some 3d canvas code is that infinities come up in
naturally harmless places, e.g. having a function that scales by x then
translates by 1/x and wanting it to work when x=0 (which ought to draw
nothing, since anything it draws is zero pixels wide), and it's a bit
annoying to track down and fix those issues, so I'd probably like it if
they were harmless in canvas methods. Opera appears to silently not draw
anything if the transformation matrix is not finite, but Firefox throws
exceptions when passing in non-finite arguments.
--
I don't personally have a strong opinion on this, and will likely just
update the spec to match what the majority of implementations do in due
course, if that changes. Currently it seems to be a bit of a mixed bag.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Partial HTML5 documents
On Thu, 9 Sep 2010, Rostislav Hristov wrote: I'm looking for a way to define valid partial HTML fragments that can be included into other documents using a server-side language or injected using AJAX. The current specification doesn't have any major restrictions in this area but it always require the presence of a TITLE tag which in this specific case is not needed. Does anybody have an idea if the TITLE can be skipped somehow or how this whole thing can be implemented properly? Do you think it should be specified? On Thu, 9 Sep 2010, Rostislav Hristov wrote: I'm actually looking into manually editing these in an authoring environment and this is why I want them to be valid. I would recommend just defining what you're trying to do as a combination of syntax elements from the spec's synatx section and content models from the spec's element descriptions. For example, you could say that your fragments are a sequence of text, character references, elements, and comments, but the text must not contain the character U+003C LESS-THAN SIGN () or an ambiguous ampersand, and the elements must be flow content, where the terms are from the syntax section of the HTML spec, except for flow content, which is from the elements section. In practice of course exactly what's allowed where depends on what you put where, which is why the spec doesn't define anything other than the validity of a whole document. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] XMLHttpRequest and HTML5
On Tue, Dec 7, 2010 at 3:48 PM, Ian Hickson i...@hixie.ch wrote: If we can do all this that should turn it into a one-way dependency with most definitions being completely self-contained. I'm not sure it's worth it in the case of the origin thing. So what happens when we define how to get a Document out of a File? We would update the HTML spec. Or, now, the File spec can define it. Either is fine by me. I still think that we should set up a post-processing step that merges all these specs into one anyway. :-) For what it's worth, this is already possible in Firefox. We support using XMLHttpRequest to load from from a File using xhr = new XMLHttpRequest; xhr.open(GET, URL.createObjectURL(myfile), false); xhr.send(); var documentFromFile = xhr.responseXML; / Jonas
Re: [whatwg] Form controls disabled IDL attribute and disabled state
On Sun, 12 Sep 2010, Mounir Lamouri wrote: With HTML4 (at least before fieldset.disabled), form controls disabled IDL attribute was a simple way to set and get the disabled state because the disabled state and the disabled content attribute were exactly the same thing. Now, with fieldset.disabled, disabled IDL attribute has no longer the same meaning. It's now only reflecting the content attribute and not the disabled state. Nothing in the API let the author knows the disabled state so the only solution is to look at the entire parent chain until a fieldset with the disabled attribute is found [1]. I can understand why when getting the disabled IDL attribute, this is not returning the state but the content attribute but I think there is a lack in the API and it might be nice for authors to have a simple way to know the state of the element [2]. This could be done with the IDL attribute returning the state instead of the content attribute or another attribute returning the state. Feedbacks welcome :) [1] if the fieldset has no disabled attribute, it still might be a child of another fieldset which has a disabled attribute. [2] some tricks might be to use query selector and check if the element has the :disabled pseudo-class applying but that's only a workaround. On Sat, 11 Sep 2010, Jonas Sicking wrote: First of all, I think setting the .disabled IDL has to map to setting the content attribute. I can't think of any other sane behavior (other than not having a setter at all, but that wouldn't be backwards compat) Second, it seems confusing to me to have the getter and setter not match. I.e. to get vs. set entirely different things. This results in weird situations like foo.disabled = false; x = foo.disabled; // x is now true and foo.disabled = !foo.disabled // This might be a no-op The result of these two statements is that I think that the spec for .disabled should not be changed. This leaves the question of if we should expose the computed disabled state thorough some other property. I don't really feel strongly about this, but as with any feature, we should ask what the use case is. On Sat, 11 Sep 2010, Boris Zbarsky wrote: Something like matchesSelector is an api on the element itself that does what you want; do we really need another api for it? Boris and Jonas make strong arguments here, so I haven't changed the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] :enabled and :disabled pseudo-classes should apply on fieldset elements
On Sun, 12 Sep 2010, Mounir Lamouri wrote: The current state of the specifications do not mention fieldset elements for the :enabled and :disabled pseudo-classes but fieldset can be disabled so I guess it might be convenient to have these pseudo-classes applied to them. Opera applies :disabled and :enabled to fieldset elements and Mozilla might do the same. It's not really the fieldset that is enabled/disabled, it's the controls within it. Put it this way: if we dropped support for disabled= from the spec, I think one would still argue that input is :enabled, but I don't think one would argue that fieldset is :enabled. Case in point, nobody argued that fieldset should match :enabled before we added the disabled= attribute to it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Which mechanisms does HTML5 have in place to combat XSS attacks?
On Tue, 14 Sep 2010, zhao Matt wrote: I know Mozilla and Microsoft have provided some ways (respectively, CSP, XSS filter) to mitigate or detect XSS attacks. so I wonder whether HTML5 will present an approach to fight this attacks? XSS is a pretty broad range of attacks. HTML has a number of features designed to prevent XSS attacks, for example the origin security policy, the iframe sandbox feature, and the text/html-sandboxed MIME type. Others have also been proposed, such as a syntax to embed text as base64 data safely. HTH. If you have any specific questions please don't hesitate to raise them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] :enabled and :disabled pseudo-classes should apply on fieldset elements
On Tue, Dec 7, 2010 at 5:08 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 12 Sep 2010, Mounir Lamouri wrote:
The current state of the specifications do not mention fieldset elements
for the :enabled and :disabled pseudo-classes but fieldset can be
disabled so I guess it might be convenient to have these pseudo-classes
applied to them.
Opera applies :disabled and :enabled to fieldset elements and Mozilla
might do the same.
It's not really the fieldset that is enabled/disabled, it's the
controls within it. Put it this way: if we dropped support for disabled=
from the spec, I think one would still argue that input is :enabled
Really? Why then isn't a div ever :enabled?
:enabled IMHO only makes sense on elements which can be disabled,
which is why div:enabled never matches anything. So if we removed
disabled= from input I don't think input:enabled would match
anything.
, but
I don't think one would argue that fieldset is :enabled. Case in point,
nobody argued that fieldset should match :enabled before we added the
disabled= attribute to it.
IMHO because it couldn't be disabled before then. Another question is,
on what basis are you saying that just the controls inside the
fieldset are disabled, and not also the fieldset itself?
I think a more important question is if it would be useful to have
fieldset:disabled match. I.e. would anyone want to use that selector
in CSS or querySelector? I have many times seen user interfaces like:
[X] Some preference
[ ] Sub-preference 1
[ ] Sub-preference 2
Where the sub-preferences are grayed out if the top-level preference
is. And it's generally not just the sub-pref checkboxes that are
grayed out, but also the labels next to them. This could be
accomplished using a selector like:
fieldset:disabled .controlLabel {
color: gray;
}
/ Jonas
[whatwg] marquee feedback
I recently implemented HTML5's IDL definition for marquee in WebKit (https://webkit.org/b/49786) and noticed a few differences between how HTML5 specs marquee and how IE implements it. I noticed the following two discrepancies: 1) For scrollAmount, scrollDelay and loop, IE does not allow the content attribute value to contain trailing non-numeric characters, although such characters are allowed according to HTML5's rules for parsing non-negative integers (section 2.5.4.1). IE will return the default value for these attributes if non-numeric characters are encountered, but HTML5 says to parse up to the first non-number and return that value. 2) For scrollAmount, scrollDelay and loop, if a value is specified that exceeds 2^31-1, IE will return 2^31-1. HTML5 says that for reflected unsigned longs, if a value is larger than 2^31-1, the default value, or 0, should be returned (section 2.8.1). Perhaps these differences aren't specific to marquee but rather true for all unsigned content attributes in IE. In any event, I wanted to point out the differences in these edge cases and ask if they are intentional or not. I'd be happy to file a bug if that's the correct thing to do. Thanks, Andy
Re: [whatwg] marquee feedback
On Tue, Dec 7, 2010 at 5:46 PM, Andy Estes aes...@apple.com wrote: I recently implemented HTML5's IDL definition for marquee in WebKit (https://webkit.org/b/49786) and noticed a few differences between how HTML5 specs marquee and how IE implements it. I noticed the following two discrepancies: 1) For scrollAmount, scrollDelay and loop, IE does not allow the content attribute value to contain trailing non-numeric characters, although such characters are allowed according to HTML5's rules for parsing non-negative integers (section 2.5.4.1). IE will return the default value for these attributes if non-numeric characters are encountered, but HTML5 says to parse up to the first non-number and return that value. 2) For scrollAmount, scrollDelay and loop, if a value is specified that exceeds 2^31-1, IE will return 2^31-1. HTML5 says that for reflected unsigned longs, if a value is larger than 2^31-1, the default value, or 0, should be returned (section 2.8.1). Perhaps these differences aren't specific to marquee but rather true for all unsigned content attributes in IE. In any event, I wanted to point out the differences in these edge cases and ask if they are intentional or not. I'd be happy to file a bug if that's the correct thing to do. Unless this breaks websites, it seems like a good thing to have consistent parsing across multiple attributes. Both for implementors and authors. / Jonas
Re: [whatwg] :enabled and :disabled pseudo-classes should apply on fieldset elements
On Tue, Dec 7, 2010 at 5:43 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Dec 7, 2010 at 5:08 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 12 Sep 2010, Mounir Lamouri wrote:
The current state of the specifications do not mention fieldset elements
for the :enabled and :disabled pseudo-classes but fieldset can be
disabled so I guess it might be convenient to have these pseudo-classes
applied to them.
Opera applies :disabled and :enabled to fieldset elements and Mozilla
might do the same.
It's not really the fieldset that is enabled/disabled, it's the
controls within it. Put it this way: if we dropped support for disabled=
from the spec, I think one would still argue that input is :enabled
Really? Why then isn't a div ever :enabled?
:enabled IMHO only makes sense on elements which can be disabled,
which is why div:enabled never matches anything. So if we removed
disabled= from input I don't think input:enabled would match
anything.
, but
I don't think one would argue that fieldset is :enabled. Case in point,
nobody argued that fieldset should match :enabled before we added the
disabled= attribute to it.
IMHO because it couldn't be disabled before then. Another question is,
on what basis are you saying that just the controls inside the
fieldset are disabled, and not also the fieldset itself?
I think a more important question is if it would be useful to have
fieldset:disabled match. I.e. would anyone want to use that selector
in CSS or querySelector? I have many times seen user interfaces like:
[X] Some preference
[ ] Sub-preference 1
[ ] Sub-preference 2
Where the sub-preferences are grayed out if the top-level preference
is. And it's generally not just the sub-pref checkboxes that are
grayed out, but also the labels next to them. This could be
accomplished using a selector like:
fieldset:disabled .controlLabel {
color: gray;
}
Jonas got it exactly. When I use fieldset disabled I'm indicating
more than the mere fact that the controls within the field set are
disabled. The entire fieldset is being disabled, and this fact will
be communicated with special styling for everything in the fieldset,
such as coloring all the text within it lighter, or giving it a
different background color.
~TJ
Re: [whatwg] Partial HTML5 documents
On 9/9/10, Rostislav Hristov rostislav.hris...@gmail.com wrote: Hello, I'm looking for a way to define valid partial HTML fragments that can be included into other documents using a server-side language or injected using AJAX. The current specification doesn't have any major restrictions in this area but it always require the presence of a TITLE tag which in this specific case is not needed. Does anybody have an idea if the TITLE can be skipped somehow or how this whole thing can be implemented properly? Do you think it should be specified? I may have misunderstood, but it sounds like you might be able to use createContextualFragment: http://html5.org/specs/dom-parsing.html#extensions-to-the-range-interface Example copy'n'pasted from c.l.js: var s = scriptalert(1)/script; var range = document.createRange(); range.selectNode(document.body); var documentFragment = range.createContextualFragment(s); document.body.appendChild(documentFragment); -- Garrett
