search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.03k stars 2.63k forks source link

Incorporate scroll-to-text into HTML #8282

Open bokand opened 2 years ago

bokand commented 2 years ago

Hi all,

I'd like to propose merging the scroll-to-text feature into HTML

Explainer Draft Spec

This has multi-vendor interest/support:

Chrome: Implemented and shipped Firefox: standards-position: positive Safari: Experimental implementation WIP

There's still a few spec issues, filed by @annevk and others, left to fix; I'll work those out before I starting on any PRs but I wanted to check in here and see if there's agreement or any concerns/objections.

Thanks!

Yay295 commented 2 years ago

What does this have to do with HTML?

bokand commented 2 years ago

Traditional fragment navigation is defined by HTML. Scroll to text is an extension of this behavior; as such, much of the draft spec is monkey patching HTML (with a few additions to DOM and CSSOM-View).

I think the new additions (i.e. non-monkeypatching; e.g. how to parse and process the directive text) probably fits best in HTML but I'm happy to take maintainer advice on where to place things.

domenic commented 2 years ago

This sounds great to me; thanks for working on this!

One thing to be aware of is that nearby portions of the spec are undergoing a rewrite in #6315. However, I don't think it should significantly effect your work, and those of us working on the rewrite will take care of any merge conflicts that come up. Maybe give that a brief skim, to confirm my instincts there.

Yay295 commented 2 years ago

Traditional fragment navigation is defined by HTML. Scroll to text is an extension of this behavior; as such, much of the draft spec is monkey patching HTML (with a few additions to DOM and CSSOM-View).

I guess that makes sense. It just seems strange to me that something that changes nothing about HTML would be part of the HTML spec.

annevk commented 1 year ago

It changes how navigation works, including navigation of HTML documents, which is all defined by the HTML Standard. In theory we only get to define how fragments work for text/html, but in practice we also define it for all MIME types that end up rendering as a document at least. Also, as it happens, most things are in scope for the HTML Standard: https://html.spec.whatwg.org/#abstract.

(I'm going to mark your comments and this one as resolved. If you'd like to discuss this further please reach out via https://whatwg.org/chat.)

marcoscaceres commented 1 year ago

Is there are PR for this? (asking for the WICG Chairs... just wondering about status as we are itching to migrate out of the WICG)

bokand commented 1 year ago

There's no PR to merge into HTML yet as I'm working out the issues in the WICG spec in-repo first - my plan was to merge once that's in good shape.

I'm actively working on this though and hope to have a PR here in the next ~2-3 weeks

marcoscaceres commented 1 year ago

ok, cool. Appreciate the update @bokand!

bokand commented 10 months ago

I'm sorry for the silence - I got pulled away on other things and didn't have a chance to complete this. However, I've carved out some time now and am making a push until I can finish this.

I have a few process questions:

domenic commented 10 months ago

Speaking for myself here, but I'd also be interested in @annevk's take...

  • I'm currently fixing the outstanding issues in the WICG repo first before starting a merge into HTML. Does this seem like a reasonable approach?

This seems reasonable to me.

  • For parts of the WICG spec that seem settled or utility, should I break them off and merge to HTML early? Or do the editors prefer a single mega-PR that includes the whole feature?

  • On a related note: should I be requesting reviews for each of the fixes and changes in the WICG spec? Or would it be better to request a fuller review once the issues in the WICG are resolved or mostly-resolved? Or just wait for review when I put up a PR into HTML?

As editor, I tend to prefer a single mega-PR as it reduces review burden and allows me to fit in the review between other work, instead of constantly revisiting the topic.

If others (especially other implementers) are more involved, then getting their review on smaller changes can be helpful.

  • What's the best place to ask questions? I sometimes find bits in the HTML spec that seem like bugs (but more likely I'm misunderstanding something) - should I just file issues here or is there a mailing list/IRC that might be better suited?

Filing issues here is good, or using https://whatwg.org/chat.

zcorpan commented 9 months ago

cc @jnjaeschke

bokand commented 9 months ago

@annevk - any thoughts on the above questions?

zcorpan commented 5 months ago

I'm happy to help with review. +1 to what @domenic said.

annevk commented 5 months ago

Sorry I missed this. I think I largely agree with @domenic as well. My thoughts:

  1. If there's some refactoring needed that can be done standalone, I'd prefer that.
  2. If the specification that's being integrated needs more changes it's probably best to make them there first. Ideally once we land the feature in HTML it won't need any further tweaks. (New features on top is a separate matter, of course.)
zcorpan commented 2 weeks ago

FYI, we plan to ship text fragments in Firefox 131.