Re: [whatwg] The src-N proposal

On 18 November 2013 23.18.37, Bruno Racineux wrote: For all it's worth, my outside take on both of srcset and src-N has always been that it's not DRY enough, and more unnecessary bloat to pages, due the long unnecessary repetition of img-path(s) for each img of similar size, repeating the same

Re: [whatwg] Add input Switch Type

On 19 November 2013 19.13.44, Jukka K. Korpela wrote: From the usability and accessibility point of view, this seems to address an important issue. Authors sometimes use checkboxes (or radio buttons) so that changing their state has an immediate effect, even submitting a form. This may violate

Re: [whatwg] The src-N proposal

On Tue, Nov 19, 2013 at 2:28 AM, Bruno Racineux br...@hexanet.net wrote: If I can give two top of my head analogies. With that pattern of thinking, something like the rather complex to understand CSS flexbox wouldn't exist. Or inline javacript would be allowed for fear of a dumb mistake by an

Re: [whatwg] Add input Switch Type

On Tue, Nov 19, 2013 at 9:28 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: It would be too restrictive to require that, and an reality, things don’t work that way. For example, if the action consists of deleting something, you just can’t repeat it next. Well, you can. Deletion is idempotent -

Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)

On Fri, Dec 6, 2013 at 2:01 AM, Kornel Lesiński kor...@geekhood.net wrote: Maybe instead of coming up with one set of pseudo-elements that's limited to the lowest common denominator we should have multiple completely different sets of pseudo-elements for each kind of interface?

Re: [whatwg] Add input Switch Type

On Wed, Dec 18, 2013 at 6:46 PM, Brian Blakely anewpage.me...@gmail.com wrote: A switch is definitely NOT simply a styled checkbox. As I mentioned earlier, you can slide/drag a switch to change its value. Also, a switch typically animates, whereas a checkbox is essentially a more static

Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)

On Fri, Jan 24, 2014 at 9:09 PM, Bruno Racineux br...@hexanet.net wrote: The requirement for ATs with 'hidden' is to access the structure of hidden elements. Not the presentation aspect... I am having a hard time translating that a resources that is not yet needed or is no longer needed means

Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)

an image or not isn't important enough (or, I think it shouldn't be) to justify entrenching in a specification. On Sat, Jan 25, 2014 at 4:13 AM, Bruno Racineux br...@hexanet.net wrote: On 1/24/14 7:37 PM, Qebui Nehebkau qebui.nehebkau+wha...@gmail.com wrote: On Fri, Jan 24, 2014 at 9:09 PM, Bruno

Re: [whatwg] input type=number for year input

On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: The number of a calendar year really does not fit into to the number model. Year numbering conveys something different than floating point numbers or even integers. Standardization of values on ISO years

Re: [whatwg] input type=number for year input

On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: I consider year-era-constructs as names for a duration of time. We can have different names than refer to the same duration of time, like 2014 CE and 2557 BE and ROC 103. The fact that most of these

Re: [whatwg] input type=number for year input

On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: CE or BE or ROC do not specify units (successor elements), but points of reference (neutral elements). In my examples, the unit for a time offset is always the duration of a solar year. Yes, sorry, by

Re: [whatwg] Supporting more address levels in autocomplete

On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson i...@hixie.ch wrote: I think the arguments you've presented so far suggest address-levelN for N=1..4, with 4=region and 3=locality, is probably the simplest thing to do. I was hoping there might be other people with opinions, to give us different

Re: [whatwg] Supporting more address levels in autocomplete

On Wed, Mar 5, 2014 at 2:54 AM, Evan Stade est...@chromium.org wrote: The majority of forms ask for tokenized data; my impression is this is necessary given their backends (be it columns in a user info database, a payment provider that requires tokenized address, etc.) So I don't think it's

Re: [whatwg] More effective model for handling resources

On Thu, Mar 13, 2014 at 6:57 AM, Tingan Ho tinga...@gmail.com wrote: Thought and feedback is welcomed Surely it would be better to send an archive file containing the resources the server expects the client to need, employing the Accept header to decide whether to do so (ie, in order to request

Re: [whatwg] HTTP status code from JavaScript

On Sun, May 25, 2014 at 8:34 AM, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Tell me a good reason why JavaScript should NOT have access to the status code? There's always a good reason not to add new things. Call it inertia; every new feature starts at -100 points.

Re: [whatwg] header for JSON-LD ???

Wow, that was unnecessary. "Working with the web since the late 90s" doesn't intrinsically make you any more right or any better a web designer than some 12-year-old from Geocities. If maintaining your worldview depends on assuming that anyone who disagrees is "too biased", your worldview is

Re: [whatwg] header for JSON-LD ???

On 23 July 2017 at 14:12, Michael A. Peters wrote: > It's a beautiful way to create structured data separate from the content, > just like layout (CSS) is best kept separate from the content. [...] I > wonder why people on this list don't like it. Reading about it was an

Re: [whatwg] header for JSON-LD ???

On 24 July 2017 at 19:21, Michael A. Peters wrote: > But if you define your structured data as attributes then information > about the other 11 is not available to machines that fetch the page and > want to know what the page offers. > It sounds like the machines

Re: [whatwg] The semantics of visual offsetting vs. verbal offsetting

On 15 September 2017 at 11:49, brenton strine wrote: > My understanding of the semantics of and vs. and is > that the former indicate a stress, emphasis, offset or importance that > would be expressed verbally, if reading aloud. > > On the other hand, the and tags indicate