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 stress, emphasis, offset > or importance that is visual or typographic. > > I frequently see people arguing that is the most semantic element > to use for a term or keyword because it is the most "important," but in a > situation where you would never change the way you read the sentence > verbally, but rather, just want the typographic indication that it's a > term. To me, I think this is coming from some ambiguity in the word > "important" that causes people to fundamentally misunderstand when to use > vs . > > Is my understanding (i.e., thinking in terms of visual vs. verbal offset as > a way of clarifying the meaning of the definitions) right here, and if so, > is there some sort of less ambiguous, authoritative document that I can > point people to when these discussions come up? Semantics conversations > always seem to come back to a fundamental disagreement about the meaning of > the words used in the W3C specification. The issue has possibly passed its expiration date by now, but no, I do not think that e.g. the definition of the strong element (as set out at https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-strong-element ) is consistent with your understanding. I don't know exactly what the W3C has to say on the matter at the moment, but most would caution against relying on their somewhat idiosyncratic perspective.
Re: [whatwg] header for JSON-LD ???
On 25 July 2017 at 17:32, Michael A. Peters wrote: > Nor does his assumption that I am "new" to the web somehow disqualify me > from making suggestions with current use cases that could reduce the bloat > of traffic. > Oh, then I think you misunderstood his statement. As I read it, "spend more time working with the web you have before trying to change it" was a suggestion to look for a way to do what you want with current technology, not an argument that you don't have enough web experience. "Spend more time" on this particular project, not in general.
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 wrong. And, btw, your worldview is wrong. Content that only some users want is separate content that should be in a separate resource.
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 probably want to fetch some kind of index page, not the page for a particular item. I think that if you find yourself wanting to send two different sets of content to different users, you probably need to be directing them to different resources.
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 > epiphany for me, it's (in my opinion) the right way to do structured data, > and far superior to sticking a bunch of attributes in tags - just like CSS > selectors are far superior to sticking style attributes in tags. > I can't speak for anyone else - I can barely speak for myself - but I think I'd argue that, intuitively, if your structured data isn't logically part of your content, there's a good chance that it doesn't belong there at all.
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. Something like this, which gives you information you should already know and is only helpful when you've already made some seriously questionable design decisions, probably shouldn't ever overcome that initial deficit. Of course, that's just my opinion, but I have a feeling I'm not the only one.
Re: [whatwg] More effective model for handling resources
On Thu, Mar 13, 2014 at 6:57 AM, Tingan Ho 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 only the lone file without whatever else the server feels should go along, the client should exclude archives from the acceptable types), &c.? I suppose it is possible that some intermediate caches may handle this poorly, but, if so, that's fundamentally just bad design on the part of those caches; I really think we just have to accept it and do the sensible thing anyway. (Ideally, by the way, we would bake cache expiration and any other relevant response header metadata into the archive format. Of course, this puts the onus on the browser to decide whether to send a separate request for a particular resource in case it has changed, not on the server to know and supply the new version - but I think this is a better way to do things, personally.)
Re: [whatwg] Supporting more address levels in autocomplete
On Wed, Mar 5, 2014 at 2:54 AM, Evan Stade 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 practical to impose address blob only on the web. Right, "impose", certainly not. But, perhaps, (one hopes,) "encourage"? Or at least "refuse to explicitly support anything else". Does autocomplete *need* to support people who are already doing it wrong? But I'm probably just being too utopian; it happens.
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson 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 perspectives on this, but it seems nobody else cares. :-( Since you asked, I think the whole endeavour (of trying to tokenise an address) is pointless and should be abandoned outright. :) Short of my ideal of *only* offering the full address (as used on a label) as an opaque string, I think it would be most reasonable to consider the 'locality' field itself to be a fully-specified opaque string, including whatever information is necessary to completely identify the location from the region level (such as the prefecture and district), rather than a single level. Failing all that, I would at least prefer for the fields to have names instead of abstract numbering, because people are likely to be confused about the order, no matter which end is the 'widest'. It also seems more intuitive, to me, for the 'locality', as, after all, 'local', to be the most specific level.
Re: [whatwg] for year input
On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp
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 'essentially' I meant that they /act/ like and can be
treated as such, as a simplification.
> The first operand is the name for a duration of time (conveying a start
> point and an end point), while the second operand is an offset. Suppose
> the result was displayed using html, like 2014:
I agree so far, sure, but note also that the year name is itself
comprised of an offset and a description of a zero point; 2014 CE is
"the year starting at the moment when 2,014 years have elapsed from
the start of 1 BC". It is itself a number of years, rendered a certain
way by convention.
> - A user agent could localize the result to 2557 BE or ROC 103 or YOLD
> 3180 without introducing errors into the calculation - similar to an
> conversion between binary, decimal and hex. Why should it be unable to
> localize the input (which is done with time zones all the time, btw) ?
Sure, you can change the number that corresponds to a given abstract
year by changing the zero, and this would depend on knowing the
original zero such that it's clear that, for example, '2014' means
2014 CE rather than BE or even BCE (presumably by specification). The
question is, is it a big enough deal that it demands a new input type,
rather than, say, a number and a dropdown with typical eras, provided
by the author? Or, for that matter, a CSS property telling the browser
to display the number following its conventions for year numbers,
which could include choice of zero just as much as grouping, as long
as the document's choice can be determined.
> - A user agent could not localize the offset, unless a separatetype=timedelta> (or similar) would be introduced. One can use an
>for a time offset quite nicely, also see below.
Yes, of course. Although I'm not sure what localising an elapsed time
would even mean (beyond the obvious choice of characters), except
possibly converting it into some non-year unit.
> I hereby - only half-jokingly - propose a @unit-type attribute for both
> and , which conveys what the given
> number represents. Thee @unit-type attribute can have the values "K",
> "s", "m", "kg", "cd", "A" and "mol" to enable hints for the seven SI
> base units. A microsyntax using the tokens "(", ")", "+", "-", "*", "/"
> and "^" could be used to specify derived units. User agents would be
> encouraged to localized the displayed data.
>
> Example for element on a cooking form:
>
> temperature
> cooking time
> beep frequency
>
> A user agent could display this - localized - as follows:
>
> temperature [ 180 °C ][+|-]
> cooking time[ 15 min ][+|-]
> beep frequency [ each second ][+|-]
>
> The @unit-type attribute could also provide useful when allowed on the
> , , and elements. Mark my words.
When I first read this, I considered it unnecessary complexity. On
reflection, though, I find that I kind of like it. Perhaps it should
be allowed for as well? Of course, I'm not sure that anyone
would really use it in practice.
However, since you mention temperature in the context of cooking, I
should point out that, in Canada (for example), degrees Celsius are
the typical unit of temperature, but Fahrenheit is often used in
cooking. Localisation to Celsius, while likely comprehensible, may not
be ideal. That said, this seems like a reason for browsers to allow
the user to choose the representation, not a flaw in the idea itself.
Re: [whatwg] for year input
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
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 calendar
> systems use a neutral element (era) and a successor function does not
> detract from that: Many contemporary calendar systems also have the
> concept of month numbering ("february is the second month") - still, in
> the interest of localization, the ISO date string value "2014-02" in
> might be rendered as e.g. "Februar 2014" (German).
This is all true, but the names we use are typically comprised,
essentially, of a number and a unit. Why shouldn't the numerical part
still be treated as a number? One would certainly use type="number"
for a mass or distance, I'd imagine, even though we can have different
names that refer to the same mass.
> Btw, a meaningful type system should probably prevent you from summing
> year numbers. "2012 CE + 2013 CE + 2014 CE" should not result in "6039
> CE", but a duration of time from 2012 CE to 2014 CE.
That seems like a good way of interpreting that, but "2012 CE + 2
(years)" must result in 2014 CE.
> I sincerely hope grouping does not become a CSS property, as it is
> locale dependent. Authors can (and will) ruin this for users not in
> their locale.
I certainly wouldn't wish to give authors any fine-grained control
over the grouping, or, for that matter, anything. Instead, I'd have a
set of fixed categories of numbers that are typically grouped in
unusual ways (vs. the general numerical case), allowing authors to
specify what kind of number this is and browsers, then, to use that
information to display the number optimally. Of course, it may be that
the number of types of numbers is infinite, but I would at least hope
that this isn't the case.
Re: [whatwg] for year input
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp 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 / > proleptic gregorian calendar could prevent quite a few errors here. Actually, they seem very clearly to be numbers (an integer offset from some defined 'zero' value, despite some complexities where the zero and direction of the offset actually differ between CE and BCE) - they can be incremented or summed meaningfully, even multiplied (although not squared, most of the time), and unlike, eg., the mentioned: On Wed, Feb 19, 2014 at 12:23 AM, Jukka K. Korpela wrote: > [...] car plate numbers, credit card numbers, product numbers, or > social security numbers [...] they can be usefully selected with varying precision (adjacent years are closely related, but the next credit card number up is completely different). On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp wrote: > Interface-wise, a dialog for without a value might > focus the current year initially - I would consider that a usability > boon. Year selection dialogs do already exist: That's certainly already possible, and would be undesirable often enough that it is better not to force it. It could make sense as a default if a value is not supplied, though. > This rule may not be so useful in general: Digit grouping using dots, > commas or spaces can be useful when comparing smaller and larger > numbers. Consider the following grouping of : > > [ 210 000 ] [+|-] > [ 19 250 ] [+|-] > [ 1 500 ] [+|-] To me, this suggests that grouping should eventually be a CSS property. But, personally, I just don't think the problem justifies a workaround until we can do that.
Re: [whatwg] 'hidden' as resources control (Was: Simplified element draft)
On Sat, Jan 25, 2014 at 4:13 AM, Bruno Racineux wrote: > What exactly do you find misguided, can you be more specific? Basically, - and I'm trying not to over-elaborate here, since my opinion isn't really very important - I just mean that I don't think there should be any guarantees about how (or whether) browsers will preload, nor any specific means of controlling this, because the way resources get loaded is not really any of the author's business. I also think that the purely presentational choice of a specific image file to represent the same content (and, even in the art direction case, they're clearly the same content if they can be represented with the same alt text; otherwise, there should be multiple img tags) should be specified in CSS, not HTML; the argument that preloaders can't consider CSS isn't compelling to me, because a browser's choice to preload 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 wrote: > > > On 1/24/14 7:37 PM, "Qebui Nehebkau" > wrote: > >>On Fri, Jan 24, 2014 at 9:09 PM, Bruno Racineux 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 that it should load immediately *regardless*. >>That seems like it should be up to the user, and, thus, the user >>agent, yes? > This is not about user-agents. Not sure what you are getting at... > > >>The question of whether and what to preload strikes me as >>very much contingent on the priorities and circumstances of individual >>users, and obviously not at all the authors' business. I find the >>entire subject of specifying how user agents should preload completely >>misguided. Shouldn't this, if *anything*, be open for innovation? > > What exactly do you find misguided, can you be more specific? > >
Re: [whatwg] 'hidden' as resources control (Was: Simplified element draft)
On Fri, Jan 24, 2014 at 9:09 PM, Bruno Racineux 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 that it should load immediately *regardless*. That seems like it should be up to the user, and, thus, the user agent, yes? The question of whether and what to preload strikes me as very much contingent on the priorities and circumstances of individual users, and obviously not at all the authors' business. I find the entire subject of specifying how user agents should preload completely misguided. Shouldn't this, if *anything*, be open for innovation?
Re: [whatwg] Add "Switch" Type
On Wed, Dec 18, 2013 at 6:46 PM, Brian Blakely 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 > interaction. Sounds entirely presentational to me. > A switch is often used to indicator more than true/false > (which should ultimately be represented). A checkbox and a switch both have two states, which can always be reduced to true/false in principle. Both are used to indicate things which may not be superficially boolean, although I would agree that using a default-styled checkbox for that (though I've seen it in the wild) is unintuitive. > Switches on the Web are currently janky, inconsistent and difficult to > implement. A good reason to make them easier to implement by styling a checkbox. > That is essentially the exact same reason that type="week" or > type="color" have value. Before formal implementations, they had been > implemented for a very long time with type="text" and mountains of dubious > code. Both have a specific meaning that wasn't adequately provided for by other input types. We already *have* a two-state input type. Making a switch out of isn't abusing anything - it's a perfectly reasonable alternative presentation for the concept.
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Fri, Dec 6, 2013 at 2:01 AM, Kornel Lesiński 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?
>
> input::calendar.month-view-grid ::first-week-row {...} // typical desktop
> style
>
> input::calendar.spin-wheel ::month-spinner {...} // iOS style
>
> (or any other syntax with cats/hats/dogs/pseudo-functions, as long as it
> groups pseudo-elements per kind of calendar UI)
>
> This way developers assuming date pickers are grids with a month view could
> style specific pseudo-elements for this layout and mobile browsers could
> ignore these styles completely.
And what happens when another implementation comes up with a
completely new interface? Do you want to specify every possible
representation of a date selector? Even if you *intend* only to
specify the (current) most common arrangements, leaving everything
else to its own devices, eventually some author will whine about not
being able to make some implementation fit their precious
meticulously-crafted "brand", and it gets all the worse if the
unspecified interfaces *catch on*. The only real solution to this
problem is for authors to accept that they don't have complete control
of the way users view their pages, and that browsers have the freedom
to innovate and develop new interfaces and other features for a
*reason*: to better serve the potentially infinite and contradictory
desires of different users.
Re: [whatwg] Add "Switch" Type
On Tue, Nov 19, 2013 at 9:28 PM, Jukka K. Korpela 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 - deleting something that has already been deleted does nothing. However, if the action a button represents is not currently applicable, the button should be disabled; pressing the button again doesn't need to be possible. In any case, I don't mean to suggest that that should be 'required', just that it is part of the concept of a button and following it where possible is likely a good idea if you want users to form correct conclusions about what things will do.
Re: [whatwg] The src-N proposal
On Tue, Nov 19, 2013 at 2:28 AM, Bruno Racineux 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 amateur.
>
> I think, this kind of false misdirected fears, are actually overemphasized
> concerns by some here. If we worry about 'stupid' so much that it hinders
> progress. It could set priorities backwards.
I think there's a qualitative difference between "this particular
thing is more complex than necessary in a way that virtually
guarantees it will be misused" and "no even slightly complicated
things should ever be allowed anywhere ever". *Not* worrying too much
about "stupid" doesn't mean that we have to do everything the hard
way, either.
> Perhaps, a reason I come to this conclusion, is that: An advantage with
> the Worpdress img-name-{width}x{height}.jpg syntax is that you don't need
> any tokens at all. As long as the With and Height are declared inline,
> you can figure out the ratio, and match that with the list of available
> widths to get the right image.
Sure, but, like I said, that only works as far as you stick to the
rigid pattern for image names. As soon as you want to break the
pattern, or - heaven forfend! - *extend* it, it becomes a serious
liability, to say the least.
> Which makes src-N or srcset ever more so unnecessary for that particular
> naming convention, that I'd rather almost have a few lines of inline
> javascript do it in the head, for the Wordpress platform.
That's great, for the Wordpress platform. Everyone else might still
want responsive images that don't require them to emulate Wordpress.
Re: [whatwg] Add "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 normal user expectations and can > be confusing. Normally, we enter some data, using various controls, > and then click on a button (or do something equivalent) to request for > an action. Checking a checkbox should not be a commitment, any more > than typing text in a feedback form or selecting an item from a > dropdown list in an order form should be a commitment. > > This means that things that have immediate effect should be buttons, > or something else recognized as action-triggering control. So why not > use a button? Maybe because a button does not normally have a visible > state. A toggle switch would thus logically be a combination of a > checkbox and a button: it has a direct effect, like a button, but it > remains visible (or otherwise perceivable) in an on or off state, like > a checkbox. And it should probably have a dual ARIA role: > role="checkbox button". > > But maybe this means looking at things in a too narrow perspective, as > if controls were only used in forms that submit data to a server. A > purely application-like page may conceivably have checkboxes and radio > buttons that have immediate effects (say, so that in an image > processing application, checking a checkbox immediately turns the > image to grayscale). Checkboxes probably wouldn’t confuse a user who > knows at all what he is using. On the other hand, toggles could be > used, too. Maybe even better than checkboxes. I think you're overthinking this. A checkbox represents an input with binary state. As I understand it, whether the input is immediate or takes effect only on some kind of submission is defined by context - specifically, whether the checkbox is associated with a form with a submit button. This does not affect the fact that the input is fundamentally binary. In contrast, a button represents a single action, atomic from the user's point of view. Pressing the button again should (it seems to me) logically perform the same action again; if the action performed every time the button is pressed can only be described as something like "toggle the X", you've done something wrong in your design. You should be able to make a checkbox look like a button (albeit, one presumes, one that remains "pushed" in order to represent its state), and *could* even make a button look like a checkbox (although I can't imagine why you would want to), but they represent different things underneath. A toggle or switch is an input with binary state. Therefore, it is a checkbox, with a different shape from usual. Incidentally, in the case of text to the sides of a styled switch, as mentioned above, it seems clear to me that the actual switch part in the middle is the input, and the text parts are labels, all inside an outer frame block.
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 pattern over and over for image galleries, and > lack of src-template (or regex pattern) approach to this problem. I agree for the most part, but URL templating, including with regexps, is definitely not the way to solve this problem. Although it's probably true that most uses will have very similar URLs with only minor changes for each image, the spec shouldn't require that, nor should it be difficult for authors to do otherwise. Many people seem to find regexps difficult to understand, and the regexps involved would only get more difficult as the complexity of URL patterns increases. Forcing authors to use them sounds like a great way to guarantee cargo-cult programming, where authors will just drop in a regexp they've seen before without any understanding of why it works the way it does or how to change it to suit their needs. This seems obviously undesirable. Personally (and I'm not a browser implementor or anything), I think the ideal solution to the URL repetition problem would be the case where authors can supply multiple base URLs for the document, and the choice of base URL is made either contextually or according to some replaced token in the relative URL string. The replaced token case could potentially be backed up by server-side redirection, I guess. This would be much more generally useful and not require people to engage with excessively complex syntaxes or name their files according to a rigid pattern.
