Re: [whatwg] HTML tags for POEM and MUSIC LYRICS

[Brian Kardell]

On Mon, Dec 11, 2017 at 9:29 AM, Michael A. Peters 
wrote:

> On 12/11/2017 04:30 AM, Jirka Kosek wrote:
>
>> On 11.12.2017 11:39, Christoph Päper wrote:
>>
>>> As with  and , HTML could also add  or something
>>> similar to embed MusicXML. Lyrics are a subset of musical notation and
>>> poems are, arguably, a special kind of lyrics (or the other way around).
>>>
>>
>> This would require change to HTML parsing rules which ideally shoudn't
>> ever happen again.
>>
>> Easier approach is to use XHTML syntax and simply embedded fragment of
>> specific XML vocabulary. It's pity that extensibility has been largely
>> thrown away when HTML5 was designed.
>>
>
> I always serve my pages as application/xhtml+xml except when an honest bot
> asks for the page (Twitter, some accessibility testers, Google Page Speed,
> all have trouble with real XML - often either screwing up with the
> self-closing script tags or parsing it correctly as XML but adding junk
> after the closing tag somewhere in their processing)
>
> I've not tried as I don't think browsers would know what to do, but one
> should be able to add other XML namespaces to html5 served as proper XML,
> no?
>
> That's how we had to to MathML circa 2000 before HTML5 (and then if I
> recall only Mozilla knew what to do with the MathML) - the same thing
> should work if browsers knew what to do with MusicXML or whatever.
>
>

Sorry, I've read through a bunch of stuff mentioned here trying to not ask
a question with an obvious answer, but I'm not finding it so: Why exactly
would this need parser change?  Is there a reason that you could you not
float custom elements that did/meant precisely what you want to help prove
that whatever particular formulation you've come up with is the set that
should be used/integrated into an HTML standard?

-- 
Brian Kardell :: @briankardell

Re: [whatwg] New tag

[Brian Kardell]

On Fri, Apr 1, 2016 at 5:55 PM, Karl Dubost  wrote:

>
> Le 2 avr. 2016 à 04:04, Daniel Murphy  a écrit :
> > we wouldn't want to waste our expensive
> > smell synthesis technology on the likes of webcrawlers and other robots
> who
> > wouldn't benefit.
>
>
> Yup. User agent sniffing definitely stinks.
>
> --
> Karl Dubost 🐄
> http://www.la-grange.net/karl/
>
>
I get a scents we should be worried about network congestion.

-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] HTML6 proposal for single-page apps without Javascript

[Brian Kardell]

On Wed, Apr 1, 2015 at 10:59 PM, Bobby Mozumder  wrote:
>
>> On Mar 31, 2015, at 12:43 PM, Joshua Cranmer  wrote:
>>
>> On 3/30/2015 10:02 PM, Bobby Mozumder wrote:
>>> One thing I’m interested in is to see more technical discussions  > around 
>>> this idea.  Like, very specific issues that show a design or
>> > concept flaw.  It’s only been about 10 days since I proposed this and > I 
>> > haven’t received much in that area.  (I did change one thing to > split 
>> > MREF from HREF based on feedback about people wanting backwards > 
>> > compatibility.)
>> Technical discussion is the last step of the process. The reason why people 
>> haven't provided technical feedback is because you have failed to motivate 
>> your proposal.

> I gave a limited one-page idea for now, so design faults should be obvious.  
> This will take years, but right now it’s looking like there aren’t 
> fundamental problems with the proposal.  Most of the unnecessary arguments 
> against it boil down to people just stuck in their comfort-zone, and those 
> people aren’t the target audience for this proposal anyways.  Javascript 
> people are going to be happy with their existing selection of MVC frameworks, 
> so why would they want anything new like this?
> The mistake Javascript developers are making is that they make the assumption 
> that everybody else is a Javascript developer.

That is just a fundamentally false portrayal and while I read between
the lines and understand your intent,  you're misunderstanding the
goals and pressures of an explainable platform that gets partially
figured out via experimental implementations.  Literally all of the
major players here are working on how to build increasingly high level
abstractions and working to compete or collaborate where appropriate.

Many of simple cases that I see that you could potentially do with
your approach as described, at least my understanding of what I've
seen so far, can in fact be done today with several frameworks
declaratively.. There is competition in the space of how to express it
and that is fundamentally no different than if we discussed it on a
mailing list, there would be different ideas.  The difference is that
one involves speculation, no testing and is useless to people in the
meantime (and the meantime means years) - very frequently only at the
end of that do you find out that 'whoops, that isn't actually what
developers need for 70% of real cases' and that scenario is a
fundamental loss at almost every level.  The issue is that that those
simple cases are, in fact, not the norm, you exceed them very quickly
and the question immediately becomes 'then what?'.  There's a lot of
competition and collaboration figuring out how you create a well
reasoned system that allows users the proper balances of power and
simplicity and ability to adapt.  To answer the same sorts of
questions that they answer every day, your solution will involve
JavaScript too - as well as SQL and some server-side specifications
which will require their own languages and probably frameworks.

I'm honestly not trying to dissuade you here or perpetuate an
argument, I'm just saying that your insistence on drawing this line to
say 'it's so simple' is, surely you can appreciate, a 'big' statement
and it doesn't seem unreasonable for people to ask you to actually
show them.  Believe it or not, participants in standards bodies have
limits to the amount of time and monetary investment they can make
into something and there's a lot to do.  Getting something started
often requires first-movers to show something, even browser makers
usually don't just throw an idea out there, they work out a proof of
concept with the proposal and show people what they are talking about.
It's not unreasonable to think that people ask you to do a little more
leg-work before they commit to ...well... even reading more if you see
what I mean... we've all got limited time.

I'm not trying to discourage you here, not at all.  If you have an
idea, I encourage you to try to develop it - find some people who are
interested, make compromises, flesh it out and come back to the list
with yourself in a better position.  I mean, it's not my list, so you
can do what you want - I just think that that's how you will see the
best results.




-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] HTML6 proposal for single-page apps without Javascript

[Brian Kardell]

tside a whole MVC
proposal and stand a better chance of entering the collective DNA of a
possible larger solution and allowing us to create an adaptable
platform, and there are definitely inroads where we can be moving the
whole idea forward along the way (I think we are actually in a sense).

Again, it's just my 2 cents.



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] HTML6 proposal for single-page apps without Javascript

[Brian Kardell]

Going to liberally snip the bits I'm responding to...

On Fri, Mar 20, 2015 at 5:10 AM, Bobby Mozumder  wrote:
> There’s a standard design pattern emerging via all the front-end javascript 
> frameworks where content is loaded dynamically via JSON APIs.  This is the 
> single-page app web design pattern.

[snip]

> Since this is so common now, can we implement this directly in the browsers 
> via HTML so users can dynamically run single-page apps without Javascript?

[snip]

> Anyways, what do you think about this?  I think something like this could 
> eliminate a lot of Javascript.  These javascript frameworks are all trying to 
> do this, but none of them do it easily and they’re always being redesigned.  
> Something should be done to standardize on it at a higher level.  There’s a 
> tremendous speed advantage in this, and we shouldn’t have to program in 
> Javascript for such a common design pattern.  Web pages should be loadable 
> with 60fps speeds and should be as responsive as native apps.
>
> -bobby
> ---
> Bobby Mozumder
> Editor-in-Chief
> FutureClaw Magazine
> mozum...@futureclaw.com <mailto:mozum...@futureclaw.com>
> +1-240-745-5287
> www.futureclaw.com <http://www.futureclaw.com/>
> twitter.com/futureclaw <https://www.twitter.com/futureclaw>
> www.linkedin.com/in/mozumder <http://www.linkedin.com/in/mozumder>


A few things worth noting:  First, we've actually tried a bunch of
this before, and you're not using it now so I think we can say that at
some level it was unsuccessful.  Second, I am going to submit for
comment that there are a couple of significant reasons why it failed
and why I don't expect we'd have much more success with it if we were
to take it up right now and you can kind of sum them up like this:
There isn't something close enough to actually emerging that remotely
looks ready and standards bodies are historically terrible at that
class of problem.

It's a really, really, really hard problem to abstract something at
such a high level which meets all of the use cases people actually
have which plays into why there are so many ever-changing solutions in
the ecosystem - they're actually trying to figure it out and that's a
good thing.  It's rarely as simple as it appears at first blush and
good ideas breed new possibilities of even better realizations.  As
the number of people using these tools increases, we gain additional
input and data - Along the way they are helping to identify where
there _are_ commonalities and suggest lower level additions that can
be standardized as well as providing necessary failed experiments that
go into finding a good solution.  In general, see
http://extensiblewebmanifesto.org or search for articles/posts related
for the thoughts of a lot of us in the community on topics like this
and, if you have an idea for what would be better - find some people
to help you build it, give people an opportunity to try it and see...
Where you can't, raise interesting questions about why and lets build
up a platform where we can make reasonable explanations to build up
higher-level proposals.

Anyway, that's my 2 cents, as they say.


-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] Confusion about node1.replace(node2)

[Brian Kardell]

On Mon, Jan 12, 2015 at 7:15 AM, Glen Huang  wrote:

> Just realize that reversing the algorithm won’t work for
> node.replace(nodes), where nodes contains multiple nodes.
>
> So yeah, replaceWith looks pretty good.
>
> > On Jan 12, 2015, at 8:07 PM, Anne van Kesteren  wrote:
> >
> > On Mon, Jan 12, 2015 at 12:03 PM, Glen Huang 
> wrote:
> >> Or, the current algorithm of replace could be reversed, which should
> eliminate such confusion.
> >
> > I think as James said that would leave the confusion. And given the
> > precedent in libraries, replaceWith() seems good.
> >
> >
> > --
> > https://annevankesteren.nl/
>
>

Yeah, libraries seem to have proven this out - unless there is a really
compelling reason to violate this, replaceWith seems to be what it should
be called. +1 to that.

-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] Notifications: making requestPermission() return a promise

[Brian Kardell]

On Oct 5, 2014 7:41 AM, "Anne van Kesteren"  wrote:
>
> On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
>  wrote:
> > So we should make a choice, as to whether we want developers to assume
they will always get permission (in which case it should reject upon
permission not being granted), or whether we want developers to ask the API
whether they were granted permission (in which case it should give back a
boolean fulfillment value or similar).
>
> How can they assume permission is always granted? It's up the user.
> It's a request from the developer and the user can say no. What's
> unclear about the name?
>

I think Domenic is saying "do we want to give the impression that you code
the happy path only in the then(), or do we assume you are asking an async
question for which an async answer is given with information for you to
disambiguate in the then() regardless of whether this is happy or not.

I originally expected denial to throw, I admit, but this is mainly because
it was guessing on an unestablished pattern. If we establish something
which can be applied widely, most of that is mitigated. I think the later
(async question that always answers in .then()) makes much more sense
especially given that https://notifications.spec.whatwg.org has 3 such
values (accepted, denied, default) - if there is algebra to be done we can
experiment with some good patterns inside .then() to make that easier.
>
> --
> https://annevankesteren.nl/

Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier

[Brian Kardell]

On Aug 23, 2014 2:11 PM, "James Graham"  wrote:
>
> On 22/08/14 19:29, Brian Kardell wrote:
> > On Fri, Aug 22, 2014 at 1:52 PM, Anne van Kesteren 
wrote:
> >> On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell 
wrote:
> >>> I still think that calling it bodyStream actually helps understanding
> >>> all you need and it's short/portable...
> >>>
> >>> response.bodyStream.asJSON()
> >>>
> >>> seems to at least give the hint that it is a stream that is consumed
> >>> without getting too crazy.
> >>
> >> Well 1),
> >>
> >>   response.json()
> >>
> >> is short too, much shorter in fact.
> >>
> >
> > It is, but there was concern that is was too short to be clear/might
> > actually be confusing before it was further shortened.  Making it
> > shorter doesn't help that objection - it doesn't make it clearer, does
> > it?  I'm not saying "this is best" I'm offering a proposal that tries
> > to strike the balance with this fact - that's all there is to my
> > comment.
>
> So my opinion is that there are two possible scenarios:
>
> 1) The API is consistent and friendly enough that, after an initial
> period of learning how it works, developers will internalize the
> semantics. In this case the short names are sufficient to describe the
> functionality and should be preferred because they increase the signal /
> noise ratio when reading and writing the code.
>
> 2) The API has semantics that are so liable to trip up developers that,
> without reminder of the behaviour, they will constantly make mistakes.
> In this case we should be working out how to design a less unfriendly
> API, not bikeshedding which function naming scheme will make the problem
> least bad.
>
> I am slightly concerned that the amount of discussion around naming here
> belies a belief that the underlying model is going to cause frustration
> for developers. Is that the case?
>

Speculation on this is tough and has IMO really stymied standards efforts.
The best way to know is to put something we think is a good effort out
there for real use and get feedback.  We're much better of when we can base
decisions on data rather than guesswork.  Ideally we could reasonably
prolyfill the API surface, but for low level primitives, this is tricky.
Is there any way we can, even if under the covers it didn't have quite the
same implications?  If so, let's try.  If not, it seems next best would be
to get in in a browser or two ASAP and leave it behind a flag until we can
collect some.  In not sure how negatively this would affect other things
like service workers in terms of delays and frustrations though.

Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier

[Brian Kardell]

On Fri, Aug 22, 2014 at 1:52 PM, Anne van Kesteren  wrote:
> On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell  wrote:
>> I still think that calling it bodyStream actually helps understanding
>> all you need and it's short/portable...
>>
>> response.bodyStream.asJSON()
>>
>> seems to at least give the hint that it is a stream that is consumed
>> without getting too crazy.
>
> Well 1),
>
>   response.json()
>
> is short too, much shorter in fact.
>

It is, but there was concern that is was too short to be clear/might
actually be confusing before it was further shortened.  Making it
shorter doesn't help that objection - it doesn't make it clearer, does
it?  I'm not saying "this is best" I'm offering a proposal that tries
to strike the balance with this fact - that's all there is to my
comment.

> 2) We have no idea what the design of what bodyStream's getter returns
> is or should be.

There was a body property, I merely proposed renaming it to
bodyStream.  If you're saying that we've definitely decided to not
directly expose the stream, merely means of consuming because of the
open question of what streams look like, then yes, that's a good
argument against what I'm saying... I might have missed that that
decision was made, was it?

> 3) As already indicated, after you use this once, you realize how it works.

Yes and no... It's moderately easier to learn if the API is clearer
about what is is, and it's definitely easier to recognize in code
without searching for context when 'response' could be several things.
It's all a balancing act of cost and benefit (see next comment)

> 4) I don't see how yours is more portable than James' proposal.

I didn't say it was, I just said it -was- portable... You could
imagine carrying the lesson that stream based properties identify
themselves as such across the platform - it's not overly long and they
would be easily recognizable - maybe that's a good balance, maybe it's
not  You could definitely make the same argument with .json(),
though it's different in the sense that there is no hint as to what
you can .json() and what you can't.  I'm definitely not saying
"bodyStream or it's wrong", but the API when I suggested it as an
option at least was discussing methods like
response.body.consumeAsJSON which is longer, less clear to me and
offers no kind of hints or portability of the idea that I can really
see.



>
>
> --
> http://annevankesteren.nl/



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier

[Brian Kardell]

On Fri, Aug 22, 2014 at 5:26 AM, Anne van Kesteren  wrote:
> On Fri, Aug 22, 2014 at 10:32 AM, Jake Archibald  
> wrote:
>> On 22 August 2014 07:20, Anne van Kesteren  wrote:
>>> That works for me too. I agree that developers will likely learn what
>>> is going on here quickly enough. And that if anything should have long
>>> names, it would be some new API that would use more memory. Jake?
>>
>> Reading a url as some format is really common, so I'm in favour of shorter
>> method names.
>>
>> var data = await (await fetch('/whatever')).asJSON();
>>
>> The consuming behaviour may catch some developers out, once, in their
>> development environment.
>>
>> I don't think Alex & Domenic were as keen & wanted something in the name to
>> represent consuming/taking.
>
> James pointed out on IRC we could simply have this:
>
>   response.json()
>   response.text()
>   request.formData()
>
> I did not like this at first. However, if we care about brevity, and
> we often said we do and act in that manner (see e.g. querySelector ->
> query), he is right. "as" does not really add anything. "bodyAsJSON"
> is a bit more descriptive and "takeBodyAsJSON" is even more, but in
> the end everyone will know very quickly that response/request can only
> have their body read once and will dislike us for having to type those
> extra characters (and will then type another couple to complain about
> it on Twitter).
>
> I checked and none of the existing properties clash with data types we
> might want to add in the future. I think those, combined with exposing
> state through hasBody should be the way forward.
>
>
> --
> http://annevankesteren.nl/


I still think that calling it bodyStream actually helps understanding
all you need and it's short/portable...

response.bodyStream.asJSON()

seems to at least give the hint that it is a stream that is consumed
without getting too crazy.


-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] [Fetch] ambiguity problem?

[Brian Kardell]

On Aug 12, 2014 1:38 PM, "Domenic Denicola" 
wrote:
>
> From: whatwg  on behalf of Brian Kardell

>
> > console. log(o.responseText);
> > console. log(o.responseText);
>
> This is why I've been advocating for asJSON() and friends to be verbs,
not nouns, i.e. readAsJSON(). Showing how you take an action makes you
think harder about whether the action will be repeatable or not.
>
> (To me, in the context of a stream or a response, "read" is not
repeatable. But others have suggested "consume" as a verb that makes this
clearer, for people who aren't as steeped in the semantics of those
objects.)

Unless I'm misunderstanding though, (you'd certainly know) from Jake's
description it sounds like it's the body  stream that gets used up/requires
cloning, which is why I suggested, just call it that.  If that's wrong then
readAs makes more sense to me.  I agree that it determines how you reason
about things.

Re: [whatwg] [Fetch] ambiguity problem?

[Brian Kardell]

On Aug 12, 2014 10:45 AM, "Anne van Kesteren"  wrote:
>
> On Tue, Aug 12, 2014 at 4:40 PM, Brian Kardell  wrote:
> > In what way? . response is a completely read DOMString or Object or
> > whatever, not a Stream?
>
> In that you cannot get back to the original response. You can only get
> it in one chosen variant.
>
>

If I do

console. log(o.responseText);
console. log(o.responseText);

The second one will be what?  The response text or nada? Isn't the later
more analogous to what we're taking about here when it's a stream?  It
feels like it's reaching for consistency but could explain how it works
either way..

> --
> http://annevankesteren.nl/

Re: [whatwg] [Fetch] ambiguity problem?

[Brian Kardell]

On Aug 12, 2014 9:13 AM, "Anne van Kesteren"  wrote:
>
> On Tue, Aug 12, 2014 at 3:07 PM, Brian Kardell  wrote:
> > Not wanting to start a giant bikeshed here but if you have a look at
Jake's
> > Service Worker Examples as an early use of fetch and streams, it seems
> > clear that many developers would be surprised by behavior of not being
> > about to refer back to the response body.
>
> Why? XMLHttpRequest does the same thing.
>
>
> --
> http://annevankesteren.nl/

In what way? . response is a completely read DOMString or Object or
whatever, not a Stream?

Re: [whatwg] [Fetch] ambiguity problem?

[Brian Kardell]

On Aug 12, 2014 9:07 AM, "Brian Kardell"  wrote:
>
> Not wanting to start a giant bikeshed here but if you have a look at
Jake's Service Worker Examples as an early use of fetch and streams, it
seems clear that many developers would be surprised by behavior of not
being about to refer back to the response body.  I'd like to suggest that
this is less a problem with service workers and more with the (current at
least) unfamiliarity with the idea that body is a stream, and maybe a lack
of recognizable way to tell the difference from native apis.  It seems like
this is always going to be the case with code using fetch, not unique to
ServiceWorkers.  I think that commonly as developers we are used to
response being a string or an already parsed object or something, and since
both will persist in the platform.  As such, I'd like to pose the idea of
changing the IDL in
>
> 5.4 Response Class
>
> To add the word stream.  I think in this case, the extra characters
aren't bad and the clarity outweighs the cost.  As in:
>
> readonly attribute FetchBodyStream bodyStream;
>
>

Whoops, missing link http://jakearchibald.com/2014/reading-responses/

[whatwg] [Fetch] ambiguity problem?

[Brian Kardell]

Not wanting to start a giant bikeshed here but if you have a look at Jake's
Service Worker Examples as an early use of fetch and streams, it seems
clear that many developers would be surprised by behavior of not being
about to refer back to the response body.  I'd like to suggest that this is
less a problem with service workers and more with the (current at least)
unfamiliarity with the idea that body is a stream, and maybe a lack of
recognizable way to tell the difference from native apis.  It seems like
this is always going to be the case with code using fetch, not unique to
ServiceWorkers.  I think that commonly as developers we are used to
response being a string or an already parsed object or something, and since
both will persist in the platform.  As such, I'd like to pose the idea of
changing the IDL in

5.4 Response Class

To add the word stream.  I think in this case, the extra characters aren't
bad and the clarity outweighs the cost.  As in:

readonly attribute FetchBodyStream
 body
Stream;

Re: [whatwg] Script preloading

[Brian Kardell]

On Aug 29, 2013 1:21 AM, "Jonas Sicking"  wrote:
>
> Hi Ryosuke,
>
> Based on the feedback here, it doesn't sound like you are a huge fan
> of the original proposal in this thread.
>
> At this point, has any implementation come out in support of the
> proposal in this thread as a preferred solution over
> noexecute/execute()?
>
> The strongest support I've seen in this thread, though I very well
> could have missed some, is "it's better than status quo".
>
> Is that the case?
>
> / Jonas
>
> On Wed, Aug 28, 2013 at 7:43 PM, Ryosuke Niwa  wrote:
> > On Jul 13, 2013, at 5:55 AM, Andy Davies  wrote:
> >
> >> On 12 July 2013 01:25, Bruno Racineux  wrote:
> >>
> >>> On browser preloading:
> >>>
> >>> There seems to an inherent conflict between 'indiscriminate'
Pre-parsers/
> >>> PreloadScanner and "responsive design" for mobile. Responsive designs
> >>> mostly implies that everything needed for a full screen desktop is
> >>> provided in markup to all devices.
> >>>
> >>>
> >> The pre-loader is a tradeoff, it's aiming to increase network
utilisation
> >> by speculatively downloading resources it can discover.
> >>
> >> Some of the resources downloaded may be not be used but with good
design
> >> and mobile first approaches hopefully this number can be minimised.
> >>
> >> Even if some unused resources get downloaded how much it matter?
> >
> > It matters a lot when you only have GSM wireless connection, and barely
loading anything at all.
> >
> >> By starting the downloads earlier, connections will be opened sooner,
and
> >> the TCP congestion window to grow sooner. Of course this has to be
balanced
> >> against visitors who might be paying to download those unused bytes,
and
> >> whether the unused resources are blocking something on the critical
path
> >> from being downloaded (believe some preloaders can re-prioritise
resources
> >> if they need them before the preloader has downloaded them)
> >
> > Exactly.  I'd to make sure whatever API we come up gives enough
flexibility for the UAs to decide whether a given resource needs to be
loaded immediatley.
> >
> >
> >
> > On Jul 12, 2013, at 11:56 AM, Kyle Simpson  wrote:
> >
> >> My scope (as it always has been) put simply: I want (for all the
reasons here and before) to have a "silver bullet" in script loading, which
lets me load any number of scripts in parallel, and to the extent that is
reasonable, be fully in control of what order they run in, if at all,
responding to conditions AS THE SCRIPTS EXECUTE, not merely as they might
have existed at the time of initial request. I want such a facility because
I want to continue to have LABjs be a best-in-class fully-capable script
loader that sets the standard for best-practice on-demand script loading.
> >
> >
> > Because of the different network conditions and constraints various
devices have, I'm wary of any solution that gives the full control over
when each script is loaded.  While I'm sure large corporations with lots of
resources will get this right, I don't want to provide a preloading API
that's hard to use for ordinary Web developers.
> >
> >
> > On Jul 15, 2013, at 7:55 AM, Kornel Lesiński 
wrote:
> >
> >> There's a very high overlap between module dependencies and 

Re: [whatwg] [html][webcomponents]: Link element in body?

[Brian Kardell]

On Wed, Mar 20, 2013 at 11:16 AM, Boris Zbarsky  wrote:
> On 3/20/13 6:27 AM, Benjamin Stürmer wrote:
>>
>> I've been thinking about this exact thing for the last few weeks,
>> because I have a use case in which it would be beneficial to use an
>> in-body  to include CSS files, especially if  could be
>> updated to support the "scoped" attribute with the same behavior as in
>> 

[whatwg] [html][webcomponents]: Link element in body?

[Brian Kardell]

Section 4.2.4 of the HTML Standard[1] contains a note:
"Note: If the rel attribute is used, the element is restricted to the
head element. When used with the itemprop attribute, the element can
be used both in the head element and in the body of the page, subject
to the constraints of the microdata model."

However, all modern browsers at least seem to respect/treat rel link
elements in the body as most developers would expect (ie, they work
just fine).

Given that this would appear to be a de-facto standard and that is to
some extent the goal of the spec (documenting what _is_ actually
standard), I'm curious as to the discrepancy... Can someone (Hixie
maybe) explain?  Is it worth opening a bug or am I missing something
important?

1. http://www.whatwg.org/specs/web-apps/current-work/#the-link-element


--
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] Mutation Observer arguments format

[Brian Kardell]

On Mar 12, 2013 12:06 PM, "Anne van Kesteren"  wrote:
>
> On Tue, Mar 12, 2013 at 3:05 PM, Brian Kardell  wrote:
> > I was going to mention this the other day - it works inter-operably
today,
> > so it seems like you probably don't want to break that.  Simultaneously
it
> > does seem to me that the API is more sensible and less confusing - is
there
> > any reason not change the proposal such that the intent is to to
deprecate
> > the existing way and consider the new/proposed API as merely
superceeding
> > the old?  Given that one is merely sugar on the other anyway - it
should be
> > possible to propose the change and augment/prollyfill the mapping I
think
> > and I see no reason you couldn't quickly roll that out natively given
its
> > simplicity.
>
> Yes, that is the basic argument made time and again. It neglects the
> costs. It takes away time from people that should probably work on
> other stuff, it increases the API surface area and what needs to be
> tested, and thereby increases the chance for mismatching functionality
> across user agents. Making changes, even seemingly trivial ones,
> across multiple independent engines is not something that should be
> taken lightly.
>
>
> --
> http://annevankesteren.nl/

Anne,

I feel like you've misunderstood my comments/observations.  Let me clarify
and see:

1) I think this API is more sensible - I had the same problem with mutation
observers api.

2) we should not be forever stuck with an unintuitive API

3) we have interop now and a mature spec, that sucks in retrospect that we
didn't see this earlier, but it is what it is.

4) this adds nothing in the way of features, it is merely sugar/better API
so it should be easily prollyfillable.  As such, I am suggesting that we
draft a proposal to do so, explain in detail how it would work (I gave a
high-level suggestion), provide test cases, etc... That's what prollyfills
are all about - a way to evolve outside the browser impl itself based on
competition and data which makes that part easier and makes sure we don't
take turns that users have problems with

... and ...

5)  should we reach that point (it is entirely possible we dont) the actual
implementation should be *comparatively *low cost.

Does it make sense?  Do you feel like I am hand-waving away any of your
concerns?  I hope not because the idea there is precisely to help address
concerns like these (as well as many others).


-Brian

Re: [whatwg] Mutation Observer arguments format

[Brian Kardell]

On Tue, Mar 12, 2013 at 6:22 AM, Olli Pettay wrote:

> On 03/12/2013 12:34 PM, Anne van Kesteren wrote:
>
>> On Tue, Mar 12, 2013 at 12:41 AM, Alex Russell 
>> wrote:
>>
>>> Thoughts?
>>>
>>
>> My main thought is that it's a pita to change the API at this time now
>> it's unprefixed everywhere and we've been encouraging developers to
>> use it in favor of mutation events. If Adam/Rafael/Olli/Jonas are
>> willing to update WebKit/Gecko though I guess I don't really care.
>>
>>
>>
> We could keep the old behavior and extend it to support types.
>

I was going to mention this the other day - it works inter-operably today,
so it seems like you probably don't want to break that.  Simultaneously it
does seem to me that the API is more sensible and less confusing - is there
any reason not change the proposal such that the intent is to to deprecate
the existing way and consider the new/proposed API as merely superceeding
the old?  Given that one is merely sugar on the other anyway - it should be
possible to propose the change and augment/prollyfill the mapping I think
and I see no reason you couldn't quickly roll that out natively given its
simplicity.


> But since the change isn't backward compatible (scripts using types
> wouldn't work in
> older browsers), I'd like to understand the need for the change.
>
> -Olli
>



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] Mutation Observer arguments format

[Brian Kardell]

On Mar 11, 2013 8:41 PM, "Alex Russell"  wrote:
>
> Hi all,
>
> I had a moment today while trying to use Mutation Observers where it
wasn't
> clear to me what bits of the configuration passed to observe() are
required
> and which are configuration about required values. In particular, the
names
> "subtree" and "childList" feel like they should be peers, but it seems
> they're not.
>
> After a quick chat with Adam Klein, it seems like it might be easier to
> understand if the "childList", "attributes", and "characterData"
attributes
> of the configuration bag were rolled into a single value, e.g. "type" or
> "types". The observe() might then be written as:
>
> observer.observe(node, { types: ["attributes", "childList"], subtree:
> true });
>
> This breaks the types of observation into a separate bag from the
> configuration for those observations.
>
> Thoughts?

Yes, i really like it :)

Re: [whatwg] [Web-storage] subdomains / cooperation and limits

[Brian Kardell]

On Sep 17, 2012 8:22 PM, "Ian Hickson"  wrote:
>
> On Mon, 17 Sep 2012, Brian Kardell wrote:
> >
> > Ian, you hit the nail on the head with the text section that raised the
> > issue but I still am not entirely sure that I understand... Doesn't this
> > imply that in a case like *.wordpress.com would have a (suggested) limit
> > of 5mb combined for all of its tons and tons of subdomains (at least
> > without additional/constant prompting)?
>
> It wouldn't be "constant" prompting, but yes, the spec does suggest that
> if you visit a dozen WordPress-hosted blogs and they all try to load a
> bunch of content onto your machine, you should probably have to give
> consent or at least be aware of what's going on.
>
I think I may be starting to fill in my mental gap here, thanks for your
patience.  I think you are saying that each subdomain does get a seperate
area, but the spec encourages prompt or at least informative communication
to the user to prevent at least obvious misuse and runaway scenarios.
Specifically what degree to which they do that are left up to
implementations...is that correct?

> > There are a whole lot of what I would call "common" examples like where
> > it seems (to me anyway) unintuitive given the regularity with which this
> > kind of case would happen to think that that is what is actually
> > proposed.
>
> What's the alternative? Allowing any site to overload your machine with
> infinite amounts of content isn't really a viable solution.
>
Blindly, sure, that could be a problem.  If a user can grant permission for
more to a particular domain explicitly, that is mostly mitigated I think.
If I understand, that is the idea with the subdomains limitations.  I will
have to do some more searching to find the conversations I might have
missed as I expect this was all discussed a while back and in following so
many lists I am just missing a few key points.

> > I can understand blocking access to that data pretty easily, but with
> > postMessage, being in the same top-level domain doesn't even matter so
> > it seems that one could just as easily "subvert the limit" that way.
>
> The difference is that getting a new domain costs money, whereas getting a
> subdomain does not. So the cost of attacking someone with subdomains is
> much lower than with domains.
>
>
> > I think it isn't really implemented that way anywhere though, is it?
> > That is, do browsers really share the limit across subdomains like
> > that...
>
> If they do not, they are likely vulnerable to this kind of griefing.

It would be great if some ms, moz, opera and webkit variant  folks could
chime in with any helpful implementaion details so we could understand the
emerging rationales about how this is being managed effectively, it might
even flesh out additional notes that could be added to the doc.  In the
very least it would be in the archives for future searches.

> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [Web-storage] subdomains / cooperation and limits

[Brian Kardell]

On Sep 17, 2012 5:22 PM, "Ian Hickson"  wrote:
>
> On Mon, 17 Sep 2012, Brian Kardell wrote:
> >
> > Essentially, x.wordpress.com and y.wordpress.com both allocate and use
> > space - no problem, right?  Access is subject to the browsers -general-
> > [same-origin policy], (leaving aside the ability to document.domain up
> > one), right?  If I have two affliate sites who communicate across an
> > explicit trust via postMessage - is this problematic?  I thought not,
> > and it doesn't seem to be - further - I cannot imagine how it could work
> > otherwise and still be useful for a host of common cases (like the
> > wordpress one I mentioned above).  I have been told that the draft
> > contradicts my understanding, but I don't think so.
>
> I don't really understand your question, but does this answer it?:
>
>
http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html#disk-space-0
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Ian, you hit the nail on the head with the text section that raised the
issue but I still am not entirely sure that I understand... Doesn't this
imply that in a case like *.wordpress.com would have a (suggested) limit of
5mb combined for all of its tons and tons of subdomains (at least without
additional/constant prompting)?  There are a whole lot of what I would call
"common" examples like where it seems (to me anyway) unintuitive given the
regularity with which this kind of case would happen to think that that is
what is actually proposed.  If so, I guess I am looking for some kind of
explanation which I haven't really been able to find to help me understand
how that came about.   I can understand blocking access to that data pretty
easily, but with postMessage, being in the same top-level domain doesn't
even matter so it seems that one could just as easily "subvert the limit"
that way.

I think it isn't really implemented that way anywhere though, is it?   That
is, do browsers really share the limit across subdomains like that... am I
just completely misunderstanding what that section is saying?

[whatwg] [Web-storage] subdomains / cooperation and limits

[Brian Kardell]

Cross posted from w3c list..

I have searched the archives and been unable to resolve this to a great
answer and I just want to make sure that my understanding is correct lest I
have to unwind things later as someone has recently made me second guess
what I thought was a logical understanding of things.  Essentially,
x.wordpress.com and y.wordpress.com both allocate and use space - no
problem, right?  Access is subject to the browsers -general- sop, (leaving
aside the ability to document.domain up one), right?  If I have two
affliate sites who communicate across an explicit trust via postMessage -
is this problematic?  I thought not, and it doesn't seem to be - further -
I cannot imagine how it could work otherwise and still be useful for a host
of common cases (like the wordpress one I mentioned above).  I have been
told that the draft contradicts my understanding, but I don't think so.
Thought that some manufactures/maybe Hixie could set me straight...?

Brian